Login Form
Main Menu
ERPGenie Websites
ERP Software Corner
Upgrade considerations for workflow
- Details
- Category: Workflow
- Published on Saturday, 09 August 2008 01:00
- Written by Kevin Wilson
- Hits: 10416
Upgrade considerations for workflow
· Batch input processing is a useful way of calling up R/3 functionality with pre-filled fields. As such, it is well suited for use within workflow where much of the data comes from the workflow container. It also allows a work item to navigate to a certain screen within a transaction, making the task easier to carry out. Unfortunately, transactions change from release to release and this is outside the control of workflow. This means that a BDC method created by a customer in one release may no longer work in the next release.
o Solution: Use BAPIs where possible instead of BDC methods. Mark your BDC methods clearly, even going to the extent of making this show up in the method name (e.g. "UpdateMaterial_bdc" ). Create a catalog of BDC methods in your technical documentation and make sure that these methods are tested using the workflow test tools in the development system before going productive in the new release.
· Synchronization of the update task. This problem is the result of optimistic workflow modeling, where an incorrectly modeled workflow happens to work in one release, but stops working in the next. . Methods that use the update task to write data should be defined as asynchronous tasks with terminating events coming from the update task itself. This guarantees that the data is written to the database before the workflow continues. If this is not the case, the next step in the flow may be executed before the changes in the previous step have been written to the database. This is particularly important for 'create' methods where the next step will fail if it uses attributes of an object that have not yet been written to the database. In other words, changes are read before they are written. This problem is particularly acute during release upgrades because the performance of the workflow system has been increased from release to release. Whereas in earlier releases the update task may have been faster than the workflow system so the data was processed in the foreseen order, this may no longer be the case after the upgrade.o Solution: Verify that all steps that write database changes have been correctly modeled. If the change is not relevant for the immediately following steps, the step can be ignored. If it looks as if there could be a timing problem, either convert the step to an asynchronous task with terminating events or ensure that the "update task" is switched off for the offending method. There is a parameter to force the "update task" to run synchronously for the CALL TRANSACTION command. E.g. CALL TRANSACTION 'MR01' USING bdc_data UPDATE 'S'. Asynchronous tasks are the better solution but require changing the workflow, so there will be situations where it makes more sense to simply turn the "update task" off for that method.
- Event triggering in HR. Prior to release 4. 0, events triggers could be customized for HR changes using the tables T588W and T588X. From release 4.0 onwards this customizing must be transferred to tables T779W and T779X in order for the events to be triggered.
- Table reference for a container is deleted. The container elements are defined referencing business objects or data repository fields. If an SAP structure is deleted or modified, the workitems and workflows may become erroneous when this change is imported during a release upgrade. Although changes to SAP structures and tables are rare, this did happen in release 4.0 when central address management was introduced. Various structures with the naming convention USRnn (where nn is a number) were changed. It is worth checking whether your containers reference these tables. If you find any, modify them in advance to reference another equivalent table. The new reference and the updated container definitions should be transported to the productive system far in advance of the upgrade.
- Tip: Create your own structure which references all the fields used in your container definitions. Include this structure in a simple ABAP report which does not have to do anything other than reference all the fields. If an SAP or customer structure that is used in a workflow is modified, a syntax error will occur in this report and you are warned. The report also prevents your system administrator accidentally deleting structures which are only referenced in workflow, and nowhere else.
· Manual activation required in Release 4.6c. This is a temporary condition but as the hot package is not available yet, it makes sense to report it here. An unexpected phenomenon in release 4. 6c is that after the release upgrade, the workflow definitions lose their cached run-time definition. This is easy to regenerate, but it is essential that this is done in the production system before going live after the upgrade.
o Use the transaction SWI1 to determine which workflows are running in the production system (check the 'advanced' flag to see workflow id. In each of these workflows, including the subflows, you must load the workflow into the workflow builder and then regenerate the run-time definition. You can do this from the display mode directly. There is no need to create a transport request or have special authorization.
· Application event triggers. It has been reported that there is a chance that an application may change their event publishing mechanism from Release to Release. Either the name of the event could change or the customizing required to trigger the event could change. It is worth checking that the events you use in your workflow are still being triggered properly after the Release upgrade. You may need to perform some additional customizing to get them triggered again.
· Delegation. Some transactions use the hard coded BOR object within the programming logic. An example of this is the event triggering of the application for the VBRK object. It appears that this has changed sometime between release 3.1 and 4.6. A consequence of this is that workflows based on your own subtype (e.g. zVBRK) will no longer work.
o The solution is to delegate VBRK to zVBRK and create the workflow based on VBRK (which has magically inherited all your new/modified methods/attributes/events). This rule applies throughout all mySAP components. If you want to extend a business object, create a subtype and then delegate it as described in the online documentation. Model your workflow using the original object type, not the "z" type. A positive side effect: You can usually navigate from the transaction that displays the business object (e.g. purchase order) to the workflow logs that involve this object. This is true, even if you have created the workflows yourself instead of using SAP delivered workflows, providing that your workflows reference the original business object (which you may have extended using delegated subobjects)
- Periodic Deadline Checking. In the SAP Web AS Release 6. 40 it is no longer possible to configure case-specific deadline monitoring. Periodic monitoring is supported and the interval between deadline checks can be customized. This has been done to reduce system load and avoid skipped deadlines when the system load is high. If you are configuring an old Release, you are recommended to avoid using case-specific deadline monitoring - configure periodic monitoring instead.
