Strategic Process Chain Design

The action of creating a process chain is rather straight forward. Once you have done a few you will be bored of the repetitive nature of the work. This realisation leads to a common approach to shove as much work into a single chain as you can possibly justify.

Process Chain

At some point your colleagues will start to object to it trying to do too much because it has gone beyond the point of being practical. This all-in-one approach in process chain developers is a natural resistance to follow a more strategic approach to building process chains.

When combined with the ‘BW automatically generated related process variants’ it leads a junior process chain builder to the conclusion that this is the way they are supposed to be designed because the SAP BW system has helped me automatically create this sequence of related activities.

Sure, it works as advertised and the data gets loaded; but how efficient was it and do you understand why some of the suggested activities are not recommended best practices?

For example: The dropping and re-creation of cube indexes surrounding a data load is a decision, not mandatory.

Indexes should be left active during a data load when:

  • The volume of the delta load is in-significantly small;
  • The volume of data already in the cube is astronomically large;
  • Your database can do row locking on indexes (not all versions of Oracle).

Finding the balance point to know if the indexes should be left on or dropped & re-created, as part of the nightly load window is only something that can be answered in each target system. It involves a range of independent contributing factors but essentially comes down to ‘test and measure’ it against your specific hardware and software configuration.

A process chain builder who does not spend time to get to know the features of InfoProviders along with a fundamental understanding of their use, is doomed to re-create inefficient process chains. One of the least optimised process chains I’ve seen was loading six Data Transfer Processes (DTP’s) into a single cube and all six DTPs had surrounding process variants that were dropping the re-creating that same cubes’ indexes (urr-ghh).

So much of the nightly load window had been wasted on index activity due to the process chain builder not spending a few minutes to ensure the BW generated related process variants were sensible. This is part of a whole other discussion regarding on-going developer training, developer mentoring, peer review processes, team leader accountability and BW support administrator handover sessions … later.

Taking a step back and looking at the types of process variants available, you will notice there are groups of related objectives:

  • Data extraction (SAP, Flat File, DB Connect, etc);
  • Data loading (DataStore, Cube, etc);
  • Data synchronisation (Change Run, Aggregates);
  • Data duplication (Forecast from Actuals);
  • OLAP engine pre-processing (Caching);
  • Data distribution (Broadcasting, Open Hub);
  • Authorisation profile adjustments;
  • Maintenance of temporary data;
  • Co-ordination of the work to be done.

Each of these objectives can be evaluated by:

  • Frequency (How often to run);
  • Dependency (Serialised and must have succeeded);
  • Seriousness (Must be done, At some point, Ok to skip).

When you start to map out your nightly load window requirements and evaluate the types of processes by their objectives; a strategy begins to form on what should be done, when and why. This evolves as discreet statements and specific rules that impact the process chain design.

As you let go of the developer resistance to build based upon your earlier experiences, you will notice that the process chains can be designed and built using simple techniques that follow an overall strategy. The process chains become simple to maintain due to their intuitive naming standard that makes it clear what they should be doing.

What fundamental strategies do I use to design my process chains?