Process chain Standards and Guidelines

 This post describes standards for building process chains in SAP BW at any generic development project. 

Process Chain Names & Attributes Standards:

Process chain technical names should begin with Z or as per your client naming conventions. 

Guidelines

Descriptions for meta chains (parent process chains that execute sub-­chains) should include “Meta” or “Parent.”

 Display Groupings:

 Standards

1. Never leave a process chain under the default, “Not Assigned,” Display Grouping. Use the Display Components toolbar button ( ) to assign new process chains to the appropriate display grouping.
2. Refer your client's SAP BW Naming Convention document for Display Grouping technical names

Guidelines:

1. If you have a large application composed of multiple logical subsystems, you may create multiple display groupings for your application. Doing so can help you organize your process chains by subsystem. Just make sure the name and description conform to the client standards.
2. To ensure that you do not leave process chains abandoned under the “Not Assigned” display grouping, consider getting into the habit of assigning the display grouping immediately after you create the Start process for new process chains.

Process Chain Scheduling:

Standards

1. Do not include, in an application ­specific process chain, loads for master data shared across applications. Instead, work with the SAP BW production support team to ensure an acceptable schedule to load shared master data on which your application depends.
2. If you have a requirement to allow end users to execute process chains on demand then work with SAP BW production team to get it done.

Process Sequence and Organization:

Standards

1. If your transaction data loads perform referential integrity checking, then ensure that your processing sequence supports the applications RI requirements.
2. You must include a PSA deletion process for every InfoPackage in your process chain. Configure the process to delete all PSA entries older than seven days, unless stated otherwise in your requirements.
3. You must include a change log deletion process for every DataStore load in your process chain. Unless otherwise stated in your requirements, configure the process to delete all change log entries older than seven days.
4. Always compress InfoCube data, leaving only the most recent requests uncom­pressed, if necessary, to allow deletion and reloading of the requests.

Guidelines

1. Use nested process chains. Break large process chains down into smaller chains, and control these via a parent process chain. Where possible, organize the sub-chains so that each one represents a coherent, standalone collection of work.
2. Put post ­processing steps, such as rebuilding indexes, generating database statistics, rolling new data into aggregates, and InfoCube compression, into a sub-chain separate from data load steps. This enables someone to execute the post ­processing steps independently of the data load steps, by running the post ­processing sub-chain on demand if necessary.
3. To minimize referential integrity errors due to missing master data, place the extraction and loading of master data between the initial extraction of transaction data and subsequent processing of that data.

If you choose to include write optimized DSO as part of EDW layer/Data Acquisition Layer, then your application includes a first level DSO for every transaction data layout. You should not have referential integrity checking for loads to this DSO, and you should have the “SIDs Generated upon Activation” flag switched off so that SAP BW will not generate SIDs for characteristic values in your first level DSO.

To avoid referential integrity errors when loading the InfoCubes, you can organize your processes as follows:

1. Extract, load, and activate transaction data in the first level DSO, without checking referential integrity and without generating SIDs.
2. Extract, load, and activate all related master data.

• Forward transaction data from the Data Acquisition Layer DSO through your InfoSources and on to the Business Transformation Layer DSO/InfoCubes.

This technique ensures that you extract transaction data before extracting the master data, to reduce or eliminate the risk that a new transaction will reference new master data that you don’t have in BW.

A Typical Process Chain:

As a guideline, the following shows the process types that should appear in a typical transaction data load process chain:

• Start Process
• InfoPackage (delta) to load data from DataSource to the PSA.
• Data Transfer Process (delta) to load data into the data warehouse (DSO).
• Activation Process for the data warehouse DSO.
• Dropping Indexes on the target InfoCube
• Data Transfer Process (delta) to load data into an InfoCube via the application integration InfoSources and Transformations.
• Building Indexes on the InfoCube
• Rollup of new InfoCube data into the aggregates
• In parallel:
  • Compression of the InfoCube.
  • Deletion of old requests from the PSA.
  • Deletion of old requests from the DSO change log.

Note that these last three processes (compression, PSA delete, change log delete) can normally run in parallel rather than in a series.

Hierarchy / Attribute Change Runs:

Standards

1. Always ensure that a hierarchy / attribute change run occurs after master data loads. Depending on the requirements of your application, you may choose to include the change run in the same process chain as the master data loads.
2. When executing a hierarchy / attribute change run process, always fill the process variant with a list of InfoObjects that the change run should operate upon. Do not include unnecessary InfoObjects.

 Process Variants:

Standards

1. You may use system ­generated variants for any process type, and you do not need to change their technical names.
2. Technical names for variants that you create and do not reuse across process chains, such as start variants, variants for AND / OR / XOR processes, etc., should begin with the technical name of the process chain in which they reside.
3. Technical names for variants that you create and reuse across process chains, such as the variants used for InfoCube compression, InfoPackages, etc., should begin with the technical name of the data target or primary object of the process. Examples: