Skip to Content

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


  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.


  • 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.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Tammy Powlas
    Hi Eddie,
    I receive a 404 error on your knowledge base article link – would it be possible for you to correct/update?

    Thank you again for this blog.

    1. Eddie Morris Post author
      Hi Tammy,

      Thanks for letting me know. I thought the KBA’s were treated in the same way as notes but this does not seem to be the case. I tried changing the link several times but no luck. Will investigate and fix asap.


  2. Mark Daley
    Hi Eddie,

    thanks for the blog, it comes at a good time in our project as we are building a WF that will have a fairly large amount of data in the container mainly stored in a Deep Struc.

    Unfortunately options to store the data in a sap/custom table and refer to it in the WF are not an option.

    I have some questions.

    As you mentioned, storing large amounts of data in the WF container will cause a rapid growth of SWWCNTP0. Is this ultimately mitigated by having pro-active archiving in place, OR are there any other performance issues with storing/passing large data in the container.

    Also, I did a simple test, I created one single char data element in a container, in SWWCNTP0 it is approx 1 line ie 1024 char. My deep struc on the other hand unfilled is 3,700char and filled approc 10,000 char. Is this an acceptable amount of space? Are there any guidlines on this?

    I’d appreciate your experiences.



    1. Eddie Morris Post author
      Hi Mark,

      XML persistence and table SWWCNTP0 were introduced to provide better performance rather than tables SWW_CONT & SWW_CONTOB. You are right, the more agressive your archiving strategy is, the lower amount of data in the runtime tables which keeps performance stable.

      I have not come across any particular issue with performance and large amounts of data in containers…this only becomes an issue if you trigger high loads of these workflows everyday and do not follow up with archiving.

      Your structure doesw not seem excessive at all. Unfortunately there is no magic number or guidelines. It all depends on frequency of execution, system resources and archiving strategy. I guess you will get a good idea when you test some scenarios and trigger some test loads. You will get an idea of possible table growth.



Leave a Reply