✒️SAP BI / Distintos tipos de ejecución Por Mary Galicia
SAP BI Distintos tipos de ejecución
Collection Process
Definition
A collection process collects several chain strings to form one string in the process chain maintenance.
Use
Process chain management handles collection processes in a particular way. The system makes the variant names consistent and guarantees that all processes of the same name that have been scheduled more than once, trigger the same event. This enables the several chain strings to be collected to form one and also makes multiple-scheduling of the actual application processes unnecessary.
The following collection processes are available in the process chain maintenance:
And Process (Last)
This process does not start before all events of the predecessor processes, that is including the last event, that it has waited for, have been successfully triggered.
Use this collection process when you want to combine processes and when further processing is dependent on all these predecessors.
Or Process (Every)
The application process starts every time a predecessor process event has been successfully triggered.
Use this collection process when you want to avoid multi-scheduling the actual application process.
XOR Process (First)
The application process starts when the first event in one of the predecessor processes has been successfully triggered .
Use this collection process when you want to process processes in parallel and schedule further independent processes after these ones.
Owing to the time components, the collection processes do not display logical gates in the normal sense, because the system cannot distinguish between whether a 0 entry (no event received), means that the event was never received or whether it has not been received yet. The reason for this is that the checks do not run continuously but only take place when the event is received.
Strategic Process Chain Design
he 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.
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.
Escanear / Compartir
Sobre el autor
Publicación académica de Mary Galicia, en su ámbito de estudios para la Carrera Consultor SAP BI / BW BO Nivel Inicial.
SAP Senior
Mary Galicia
Profesión: Ingeniero en Informatica - Venezuela - Legajo: JZ82V
✒️Autor de: 47 Publicaciones Académicas
🎓Egresado del módulo:
Disponibilidad Laboral: FullTime
