As the features of BW and your ability to implement them grow, so too does the need to automate those features. Process chains are used to automate most of the activity within BW and they help by:
- Removing manual intervention (lower the risk);
- Executing configured activities, repeatably;
- Co-ordinating sequence of activities (dependency, timing, etc);
- Communicate status to people and systems.
There are two fundamental aspects of process chains:
- Process variants contain the configuration;
- Process slots execute the process variant.
One responsibility of the basis team is to configure the process slots within the SAP Netweaver system. The default configuration for a fresh installation is enough for the system to boot up and execute some very basic activities. This default configuration should never be used, even if it is just a development, sandpit or training system.
By not requesting the basis team to increase the number of process slots available, you will waste a significant amount of time (which is money) while waiting for system resources to become available.
This is most notable when two developers execute a data load and the system fills up all the processing slots. Technically the system is up and running, however it will not respond to requests from the SAP GUI, BEx Analyser, Portal reporting or any other external application that wants something from the BW system. This is because there are no process slots available to process any further requests.
At this point you have two choices:
- Stop processing so much at the same time;
- Increase the number of process slots.
A common reason why the BW system occasionally appears to crash (but is only not responding) is because the process chains themselves have been built without any consideration for resource usage. The BW developer was more focused on achieving the goal and ensuring the data was ok. If a little more time had been spent on reviewing the topic of parallel execution then quite a few support tickets and late night support calls could have been avoided.
“build process chains with parallel execution in mind”
The topic of parallel execution and process chains has two main aspects:
- The number of process slots within each process variant;
- The number of process variants across the process branches.
Quite a few of the process variants are capable of achieving their goal by breaking the activity up into separate, smaller programs that work independently from each other. The BW system then has the ability to execute these smaller programs side-by-side (in parallel). The maximum number of parallel programs to execute is configurable; there is a system default (usually 3) which can be overridden.
Process Variant Example: The individual DataPackets within the process variant for Data Transfer Process (DTP) execution.
Multiple process branches can appear within a single process chain or be the execution of two process chains at the same time.
Process Branch Example: Executing the process variants to load the independent master data texts for 0CUSTOMER and 0MATERIAL within the same process chain at the same time.
Process Branch Example: Executing a process chain that has two process variants which are entire process chains themselves. Loading master data texts process chain in parallel to a staging layer transaction data extractor process chain.
With the above examples in mind you can follow a basic guideline for building process chains that considers parallel execution and avoids resource bottle necks. At its simplest, this can be achieved with keeping nested process chains to only 1 level deep and utilising the system default for parallel execution. The top level process chain is utilised more for co-ordinating the macro level execution of big objectives while the nested worker process chains achieve the individual goals.
This would allow you to calculate the maximum number of process slots required to avoid resource bottle necks. A 2<2<3 process strategy would be:
- 1 → 1 Main process chain is triggered;
- x 2 → 2 Meta chains execute in parallel;
- x 2 → Each meta chain executes 2 process variants in parallel;
- x 3 → Each process variant can consume up to 3 process slots;
- = 12 process slots required.
With quite a few process variants, the parallel execution will consume the number of slots configured (like 3); however there will occasionally be a need to run a very, very small status update program in parallel. This officially means that the number of process slots configured for parallel execution is not the complete number of process slots utilised to achieve the goal. You should always have at least 2 additional process slots free for these small update programs to quickly jump in, execute and jump out.
Now take a look at your systems process chains and get a feel for the level of parallel execution that is occurring. Can you see it clearly or is the process chain design a complex mess of unbalanced branches?