Workflow "objects" need to be send across the system landscape like any other "object". This article is about the (often troublesome) aspect of workflows: transport & correction.

Version managment perks

There's a few facts of life you need to be aware of in Workflow version management. Here's a

Shortlist:

• Whenever changes are transported, a new version should be generated and activated. If this is not done, there is a more than fair chance the receiving system will introduce the "Runtime version" of your flow, which is effectively the version before the new version. Very annoying...
• Be aware that flows which have started before a flow change is introduced will not restart. Hence old flows need to become extinct before the new flow will be used everywhere. The version system is clever enough to hang on to the version the original flow started on. A possible solution would be to actively remove and restart all active flows - if that is at all possible... (depends on the workflow). Thus: version management makes sure old flows keep running on their old definitions...
• Exception to the above (1): A tricky trick on Subflows - when a subflow is changed and e.g. the binding from main flow to subflow is changed as well, existing flows will attempt to call the renewed subflow from the old workflow definition. Again: room for error and confusion...
• Exception to the above (2): when a Method or the function module that is called from a method is changed, the old workflow will call the new Method - which leaves a bit of room for error and confusion...
• Version management on the coding in the Business Object is available via the normal program editor for the main program of the Business Object, e.g. RBUS2012 for BUS2012 which can be found on the "Basic data" of your BO. Use transaction SE38 and go to the menu: Utilities > Versions > Version management.
• Whenever a new version of workflow is introduced in a new system, run transaction SWU_OBUF - "Synchronize runtime buffer" to make sure all newly introduced stuff is actually used/called.

Developing / activating workflows and client dependance

On a development system with e.g. 5 clients, activating an event that is a a triggering event for a certain workflow could potentially trigger a lot more than was catered for. Hence the activation of events is a client dependant setting. So what other settings should be done in the client that is transported from ? Some inside info: Transporting workflows is a rather elaborate thing. Workflow is set up with a wide variety of objects and object types, which are prefixed with a 3-digit number that can be set up per client. Just for the idea: there are 108 possible object types, of which Job, Position, Rule, Role, Workflow Task, Workflow Event and User are but a few. In effect, the main tables with objects are client independant, as client dependance is arranged in a different way. E.g. A task is set up client independent but it´s activation is client dependant. Thus: to transport stuff accurately, beware of activations. Here´s a

Checklist:

• Developments for workflow - Go ahead and develop whatever you need to develop. Transport will be created and actual workflows cannot even run if they are not on a transport. Underlying programs, and a wide variety of objects will be held on transports that you will be prompted for.
• Type linkage: activation of workflow - To activate your work, triggering events may be activated on the actual task definition. This will activate the workflow on the system (client) you are on, but no transport will be created for this, unless you are on the client that records changes (which is normally the case). After work has been done, go to the client that is used to transport from and go to Business Workflow > Development > Definition tools > Events > Event linkages > Type Linkage. Via Transport (in the menu) a transport can be created with the type linkages required.
• Triggering events: starting conditions - Where starting conditions are used (changed), do make sure these changes actually end up on a transport. From SWB_COND the main menu shows Extras > Transport.
• Standard task, agent assignment: possible agents - Where tasks are setup that result in Work Items in the end-user inbox, possible agents must be maintained. It is a project-wide standard that tasks are set up as "General task" which means there are no restrictions to possible agents. These settings must be repeated on the client from which transports are released and exported.

Note:this checklist only applies when working on a client from which transports will not be done. When working from the client from which transports are executed, popups for respective requests will automatically follow.

OSS note number: 571302 Collective note relating to transports in workflow

• Prev