Process Life Cycle Demonstration

The following example demonstrates process life cycle:

1. Define a process with hierarchical model.
2. Debug the process / Test process from developer point of view.
3. Release the process
4. Deploy the process (to integration test environment, to productive environment).
5. Activate the process

1. Define processes

Define processes in status in development by action create new process definition.

Notice that the version is 0. Process in Development has only one instance without version.

2. Test

Test the process GPL.UseCase1.TLA by action “Test” in Process Modeler.

You will get an info message - called processes must also be tested.

All red coloured processes will be copied or replaced.

If you agree then press “OK” otherwise “Cancel”.

The action creates a testing copy of processes. Your developing environment is free to make any changes during your testing phase. Solve concurrent access of process engineers to different parts of process sub-trees.

The last step of the action is to open the test copy in Modeler:

Test your process with the “Start” button on the main TopLevel process.

It opens your new process instance.

You may want to test/debug some parts of the process which are hard to reach if you start the test case from beginning, so the “Start” action can be run directly on global processes or event triggered processes. You will be asked to manually enter input parameter if required.

Test process GPL.UseCase1.GlobalProcessD.Level2 by action “Start”

Your process instance is created and opened.

During your developer test you may experience errors etc. Everything is under your control. You can start not valid processes, you can enter wrong values by accident.

Warning: We don’t provide warranty that the process engine will survive all situations. Be prepared for PE restart and data clean up.

Test copies of processes have version 0, which means no version. There is only one instance of the test copy per process. Test copies are marked by status “Debug”. You can't have a process in both statuses ‘Debug’ and ‘Active’ at the same time on one DB.

3. Release the process

Release process GPL.UseCase1.TLA tested version into status “Released”

After a successful test you are ready to release your process. Prerequisite is that the process and all dependent processes are valid without any errors.

You will get an info message - called processes must also be released.

See the result:

4. Deploy process (to integration test environment, to productive environment)

Export process for deployment (…\VM4.4\GPL\Usecase1.xml)

Productive environment

and import into Test/Production DB – take care that it is without conflicts!

5. Use action Activate on “GPL.UseCase1.TLA"

You will get an obligated dependency dialog.

Result: 3 active processes.

When we open the active process in modeler then we can check that all references are correct.

Start 2 instances to simulate a user working on productive environment.

PI-0000014803 is already completed and refers the active process definition version 1 deployment 0, there are also PI-0000014804, PI-0000014805 - called global processes.

PI-0000014802 – is running and waiting until the user completes the user task. This takes a long time. Let us create a new version of global process “GPL.UseCase1.GlobalProcess.C.Level1" and we will check how the process ends.

1. Create new top level process which calls your global process structure.
2. Test it
3. Deploy
4. Activate

6. Create new process in status "InDevelopment"

The new process is connected to the global process GPL.UseCase1.GlobalProcess.C.Level1 which is in state “InDevelopment”. There are no cross references between processes in different versions. We have one development environment.

7. Test the process

Test process GPL.UseCase1.TLB by action “Test”.

There is no dialog because no dependant changes are necessary.

Note: Test copy of process "GPL.UseCase1.TLB” refers to existing test copy “GPL.UseCase1.GlobalProcess.C.Level1” created in the previous use case.

If you delete this test copy then new test copy must be created and it would lead to new release later now.

8. Release process

Released “GPL.UseCase1.TLB” version 1 refers to the existing release of “GPL.UseCase1.GlobalProcess.C.Level1” version 1 created in the previous use case.

Export the process.

and import on Productive/Integration Test environment

Again - no conflicts.

9. Activate process

There is no retired version yet. The new process GPL.UseCase1.TLB is connected to GPL.UseCase1.GlobalProcess.C.Level1 version 1, deployment 0!

After a successful test the xml is ready for deployment to productive environment without any change! Import xml to productiion and Activate the process as on Test environment. The result must be the same like on the picture in Step 8.

1. Continue developing of global process GPL.UseCase1.GlobalProcess.C.Level1.
2. Developer test
3. Integration test
4. How to solve problem
5. Deployment and Activation

10. Change Node

Open end edit GPL.UseCase1.GlobalProcess.C.Level1 development version and make new node.

11. Developer test

-as described above in step 2.

1. Press the "test" button.

   

2. Test your change, isolated or in context of test cases GPL.UseCase1.TLA and GPL.UseCase1.TLB

   

12. Deploy and Activate

After successful test release of the process "GPL.UseCase1.GlobalProcess.C.Level1 version 2", create xml and deploy it to an Integration Test environment, Activate process

With the “Release” action we make more released versions from one stable development environment (all processes are situated there only once). At the end it could be very hard to recognize what will really be used because we lost dependencies to the called process and it is not possible to filter process catalog the way: “Get me the latest version of all processes”. There is a new attribute “processAge.ageTotal” with semantic - the last version of process has age 0 and the first version of the process is the oldest one. You can filter catalog by this attribute and get only the latest versions of processes.

Picture shows a situation after the release of "GPL.UseCase1.GlobalProcess.C.Level1 version 2". We can see that version 1 is now the oldest version of the process with age 1 and this age 1 is also there for status “Released” because version 2 is already “Released” as well.

Export xml will contain only one new process.

Import into Test environment without conflicts!

Activate the process "GPL.UseCase1.GlobalProcess.C.Level1 version 2". See that there is only a new deployment "1" for this process, old version 1 is Retired.

The new active process is correctly called from GPL.UseCase1.TLA/TLB and also refers to the right version of GPL.UseCase1.GlobalProcess.D.Level2

The old version has no caller, but still refers to the right GPL.UseCase1.GlobalProcess.D.Level2.

12. Integration Test Fails

The integration test might fail, because you made a mistake or didn’t take some situations in to consideration. If you do good development testing then you reduce bugs to a minimum! You should experience mainly these problems:

• There are different data on Test environment and your process is not able manage it. It could happen because on your development database this situation could not occur. Your process contains a bug and you have to fix it.
• Tester or customer is not satisfied with behavior which is not according to specifications. This is a design bug and you have to change the process.
• Tester or customer is not satisfied with behavior even when it is according to specification and this is a request for change. You have to change the specification and the process as well.

In that case just go on with your developer version best start point for your fix/change and continue in the life as described above or use the action “Get Content” to replace your developer version with the version you'd like to use as a start point of your fix. In our example we have GPL.UseCase1.GlobalProcess.C.Level1 development exactly the same as GPL.UseCase1.GlobalProcess.C.Level1 version 2.

but that was a wrong change. and we now want to go back to the previous version and start again from scratch.

Use action “Get Content” which creates or replaces development the version of process.

13. deployment and activation

-exactly the same way like on the Test environment.

The process PI-0000014802 is still running.

Lets’ finish this process.

You can see that PI-0000014802 finally calls GPL.UseCase1.GlobalProcess.C.Level1 version 2 J

If we would want to change the interface of the global process we would have to change all callers as well. But that would lead to a problem with already running process instances of callers! The problem is that in that case we wouldn't be able to just switch the reference in the call activity but we would also have to create new input and output parameters. All running processes would have to call the “Retired” version of the process and that doesn’t fit to the axiom that all new process instances are started on an “Active” process.

Basic rule:

Keep interface stable. If you really need changes - create a new process and not a new version!