Dr. Workflow :)

[Former Member]

Hello all…..

Couple of points is based on my experience and some of them are collected on workflow testing.

The best way of ensuring a smooth and trouble-free introduction of your new or changed workflow into your production environment is to vigorously test and comprehensively document the development work in advance. This is particularly true of workflow where trouble shooting is more complicated than traditional programs.

Testing new or changed workflows:

                There are many test utilities in the web flow engine and you should take an advantage of them where you can.

You can use the following sequence as a general process for testing a typical, brand new workflow from scratch.

Business Objects Test:

Use the Business Object (BO) test option (accessible from BO builder or from the diagnosis tool test environment by choosing the relevant BO) to check that all new and changed attributes are working correctly.

Test Methods:

Use the BO test option to test any new or changed object methods. This includes testing that exceptions are raised by methods in the appropriate circumstances. Unless you are testing an instance independent method (such as Create or Find) you will need to create an object instance first. This is simpler than it sounds. You simply create the BO equivalent of the application object you want to test by choosing “Create Instance” and specifying the key of object. This reads the table in the SAP database for this object key to build a virtual business object equivalent that you can then test. Bear in mind that the methods tested are not simulated they will really do what they are meant to do. E.g. method “Purchase Order.Delete” really deletes the Purchase order.

• Ø If you need to debug a method, it is easiest to put a breakpoint statement into the method itself, prior to running the test. Do not forget to remove the breakpoint after words. Make sure that you turn on the debugging switch in ‘setting’ menu before you start to debug the method.

Test Task/ Workflow Consistency:

Perform a consistency test (this is like a syntax check in the program) on the workflow and all related tasks and event using Tcode SWUD.

Test the Agent Determination Rules:

Simulate the Agent determination rules used in the workflow by using the rule simulation in the rule editor (Tcode PFAC). You can also check the results in the _RULE_RESULT container element if you have defined a return binding for the agent determination rule (it is available from release 6.10). It can be useful to define this binding just so that you can easily track any problems in that productive environment.

Test the Workflow and Sub workflows:

            Use the start task tool to test each sub workflow and then the workflow as a whole. If you are having binding problems, turning on the workflow trace can be useful. Do not forget to turn them off when you are finished.

Useful link on workflow trace: http://scn.sap.com/thread/3179666

Test the Event Linkages:

                Use “Simulate Event (SWU0)” to check that event linkages for triggering  and terminating events you are using are defined correctly and activated.

Test the triggering events manually:

                Use ‘Create Event’ to trigger the event manually and the Event Trace to check that they affect your workflow in the way you expect. Simulate any start conditions (or check function modules or receive type function modules) used to trigger the workflow.

Test the Authorizations:

Most developers in the development and QA systems have more authorization than the users in the production environment. It is essential that before going live, you test the workflow with authorization profiles that the operational users will have.

Test Error Scenarios:

                Once everything is working correctly, do not forget to test all possible workflow paths, including simulate error solutions to make they behave as expected. You do not need to model a response to every possible error in your workflow but it is vital that serious errors throw an exception so that if one does occur the default Webflow Engine  error handling andthe administrator can catch the errors and resolve it. Be particularly careful to simulate any error situation that might be caused by neglected or incorrect data maintenance.

                If you need to test deadlines in workflow, avoid putting short deadlines in your workflow step, which you may forget to remove later, it is better to put the real deadline times in your workflow steps. You can then check that the correct deadline time is calculated, and change the deadline (from work item display, choose Work Item ----More Functions----change Deadlines) to verify that escalation process is working. Do not forget to check that dead line background job has been activated

Thanks & Regards,

Murali Krishna.