eddie.morris

    3 Posts

    Cause

    • When making changes to or creating a new workflow template you also create other new objects e.g. standard tasks, workflow container elements based on new data references, new business object subtypes and so on.
    • You do not transport these new object to your system, you only transport the workflow template.
    • When you transport a workflow template it does not automatically transport other objects like standard tasks or data references. These new object must be transported seperately.

     

    Resolution

    If you have already transported the workflow and it will not activate in the target system then carry out the following:

    1. In the target system, open the workflow template in the Workflow Builder (Transaction SWDD or PFTC) and do a syntax check. In the bottom of the screen it will list any errors. If for example a standard task is missing from the system it will have an error like "TSXXXXXXXX is not a valid object".
    2. Transport the identified missing object to the target system, refresh the runtime buffers with transaction SWU_OBUF (in target system) and check the workflow template again. It should be possible to activate it in the target system.

    When you make changes to existing workflows or create new workflow templates make sure you transport all new objects before you transport your workflow template. For example you could transport your objects in the following order.

    • Newly created business object subtype (or changes to existing business object subtypes)
    • Newly created standard tasks (or changes to exising tasks)
    • Newly created data dicitionary objects which are referenced by workflow container elements (or existing data dictionary object that have been changed)
    • Workflow template

     

    Additional information regarding Workflow Template Versions

    This is how versions work in relation to transporting workflow templates:

    • Create or make a change to a workflow in your development system and transport it to Test.
    • If the workflow already exists in Test and it has running instances then a new version of the workflow is created automatically in Test. This is done so that the existing instances can use the old version and new instances created after the transport can use the new version. If the workflow already exists but had no existing instances (in Test) then it would simply be overwritten with the new transport.

    You do NOT need to have versions synchronized between  your Development, Quality & Production systems.

    This information can also be seen in the Knowledge Based Article 1603745.

    You notice table SWWCNTP0 growing at a much faster pace than the other workflow runtime tables. 

    Cause

    1. You have not implemented a work item archiving strategy in your production system.
    2. You use multiline container elements within your workflows which contain large amounts of data.

    Resolution

    • Please put a WORKITEM archiving strategy in place so you can keep your workflow table size under control. Use transaction SARA and archiving object WORKITEM in order to archive work items. Please review note 573656 for more information. The lower the number of entries in the workflow runtime tables the better the performance of the workflow engine. Table SWWCNTP0 is one of the workflow runtime tables.
    • Deleting unneeded table entries - Run report RSWWWIDE_DEP in order to remove entries in the workflow runtime tables that do not exist in SWWWIHEAD. You can run RSWWWIDE_DEP for all the tables listed in order to clean up the tables which include SWWWIHEAD, SWWLOGHIST and SWWCNTP0 among others. In this case please run it for table SWWCNTP0. After a delete or archive it is usually a good idea to do a Reorg. See note 72873.
    • Containers - From release Basis 640 onwards container values of work items are written to table SWWCNTP0 by default rather than tables SWW_CONT and SWW_CONTOB. This is called XML persistence and the data is stored in an XML table which improves the performance of the workflow execution.  The size of table SWWCNTP0 will depend on how many work items are generated in the system and how much data is contained in each container element of each work item container. If you have multiline container elements that contain many entries (At runtime) you need to establish if all this data is needed in the workflow execution. If not then you need to revisit the design and binding of your workflow definitions. Table SWWCNTP0 will be smaller when you have less work items in your system (Archiving) and less data in your container elements (Workflow design). If you wish to use the old container behaviour (Fill tables SWW_CONT & SWW_CONTOB) you can change the settings for the persistence profile of a workflow via the Workflow Builder (Transaction SWDD) => Basic Data (Button with Hat icon) => Version Dependent tab => Control tab. Look in the 'Persistence profile' tab and you can change the settings. However XML persistence is better regarding workflow performance.

    This information can also be seen in the Knowledge Based Article 1552169.



    You notice that a particular workflow or workflows are no longer being triggered or that users are not receiving their work items in their inbox as expected. Your Workflow Administrator also receives error notifications in their SAP inbox with title "Error in event receiver". (Transaction SBWP - Documents folder).

    Cause

    In your event linkage in transaction SWE2 you use the default system behaviour regarding handling errors.

    SWE2

    AND

    Incorrect or corrupt data being passed from the triggering object event container to the event receiver/workflow template container.

    OR

    No data being passed from the an object event container element to a mandatory workflow container element. If a container element is flagged as mandatory then it must receive data when the workflow is being triggered.

     

    Resolution

    [1] Change the default behaviour of the event linkage in transaction SWE2.

    The default settings in SWE2 for the linkage between an object event and a workflow template are as follows:

    You can see the Linkage Activated checkbox which shows if the event linkage is active or not. If a problem (mentioned in the Cause section) occurs this checkbox is deactivated when the Behaviour Upon Error Feedback = System defaults.

    Set the Behaviour Upon Error Feedback = Do not change linkage and Receiver Status = No errors.

    If an error is returned, the linkage is not changed. The event is stored temporarily for redelivery. If more events follow for this linkage, attempts are made to start the receiver. If an error is discovered, the relevant events are stored temporarily. With this configuration, only those events for which the error has occurred are stored temporarily. Receivers/Workflows with no errors (based on the event parameters) are started immediately. 

    Carry out the steps detailed above for all your active event linkages in SWE2.

     

    [2] Establish the reason for the error in the first place

    Carrying out the steps in [1] above will prevent the event linkage from being deactivated. However, it does not resolve the error that occurred in the first place so you must now troubleshoot this issue in order to stop the error and redeliver any events in error.

    When the event linkage gets deactivated, a mail is sent to the SBWP of the WF administrator, detailing the cause of the error. Ususlly this is due to incorrect data being passed from the Object event to the event receiver/workflow template. Please check the inbox (Documents - not workflow inbox) of the Wf admin for mails/notifications around the time of the deactivation and it will detail what error has occurred.

    OR

    Activate the Event log (transaction SWELS). As soon as the linkage gets deactivated again, please check the event log with transaction SWEL and it should have an entry for all successful events but will also have entry for the one that deactivated the linkage. If you double click on this it should give some information on why this is happening. (It is not advised to leave the Event log switched on in Production for long periods as it may cause performance issues. Switch off once the linkage is deactivated).