Previous Topic

Book Contents

Book Index

Next Topic

Communication between processes by message flows

Beginning of the development.

Help Image

Test (on GPL.UseCase3.Conversation.Initiator) – both are set to test without the confirmation dialog (if there are no conflicts then we don’t disturb the user). It’s no matter if you do it on Initiator or Participant. I suggest Initiator because then you can directly start the test of both processes. If you do it on participant then you can test only isolated process.

Help Image

Situation in DBRelease (on GPL.UseCase3.Conversation.Participant) – we should again release the Initiator directly, but we'll try it on the Participant to demonstrate that it really doesn’t matter.

We are informed about dependencies and have to confirm release.

Help Image

Help Image

Activate – both processes are activated together even when you activate just on one of them, because of message flow dependencies between them

Help Image

Help Image

Now we show only some situation during further development of processes

Help Image

Activate – GPL.UseCase3.Conversation.Initiator version 2

Help Image

Note that GPL.UseCase3.Conversation.Initiator v2 deployment 0 is “Retired”.

Change process Participant – Test – Release

Help Image

Help Image

Situation among released versions when we do changes step by step. It leads to message flows between versions.

Activate – the same situation, old versions are retired

Help Image

Change both processes Initiator and Participant before Release

Help Image

There is no mixture between versions because we have a new version for both processes.

Activate – the same situation like after release

Help Image

See Also

Example

Processes with one Message Flow

Communication between processes without message flow

Hierarchical process design