Process Context Keeping it clean and simple:
1.Making automated / human activity output as a "Data Object" in process context:
Easy way: Just by dragging and dropping the output context of an automated / human activity in the canvas, one will end-up creating hanging attributes in the process context which are not relevant or not required for the execution of a given process.
Better way is to pick up the required attributes and its type smartly from output context of an automated / human activity and create the same in a Data Object.
Benefits: Cleaner and uncluttered process context will make the process more robust and lean. Sometimes it not possible to keep the Data Object simple because of the frequent changes to the underlying structure (i.e if you decide to use some more attributes later and find it absent from Data Object) in such case please refer to the point 5.
2. How many Data Objects?
Easy way: Create only one Data Object and keep all the attributes and data in that. You will end up in creating a large data object which will make the process context heavy and slow to load with many irrelevant attributes at a time.
Better way: Again choose smartly based on how many processes and sub-processes are there, and care should be taken to ensure that the context of the sub-processes are not loaded with un-required attributes.
Benefits: Lesser the number of data object the faster the process will be and there are certain limit on the size of process context which you can keep, so to be on safer side choose wisely. Even if the relevant sub process to which the particular data object belongs is not alive it will create the empty data object with null values which means it will any ways make the process heavy.
3. Keeping only few Data Objects for distributed process as well:
The idea is to keep the processes distributed and less number of Data object for those process in a way to avoid redundancy of the attributes resulting less load on the process context.
Easy way: Creating separate data object for each lane or automated / human activity and creating less number of sub-processes to counter that.
Better Way: Keep less data objects with generalized attributes in it which can be consumed by maximum number of process and sub-process. Create the process with number of sub-process required to make it more decoupled.
For Example: If in a process model there are many similar activities containing the operation like getEmployeeID, getDeparmentId, getManagerId and getInvoiceId with the attributes like Employee Id, Department Id, Manager Id, and Invoice Id we can create four attributes, one for each or we can create one attribute for all, called ID which will help to reduce the weight of process context.
4. Avoid nesting as much as possible:
The idea is again to keep it simple because nested nodes causes unnecessary complexity and defeats the purpose of reusability because nested Data Objects can’t be used by most of the activity which doesn’t have similar nested structure.
Easy Way: Creating the Data objects using complex type which are nested in structure and contains different cardinality nodes for different Automated/Human activity.
Better Way: Avoid nesting for data objects if a different cardinality node is required create a separate data object of particular cardinality and map it to the activities.
To avoid nesting refer to point 5. If it’s absolutely necessary to create a complex type, then refer the article Creating and using Custom Data Types in SAP NetWeaver BPM 7.2.
5. Use the wrapper to keep it simple:
It is a good idea to use the wrappers for BAPIs / RFCs and other services (web-service or EJB-function) which holds the entire super set of data. It is highly unlikely to change the business process model often as it is more closely related to business automation and most of the time business process are modeled by a different business person who will not like to alter the structure.
Easy way: Assigning the standards BAPIs / RFCs as it is and creating the data object and remodel the process to incorporate with that which will save some time.
Better way: Keep it simple by creating wrapper on top of the web-service or EJB-function or the RFC used in the automated / human activity , by this you will be able to change the number of required attributes at any point of time by modifying the wrapper.
