处理链中ABAP+选择
Using ABAP with Process Chain Decision Processes
In this document we're going to discuss controlling the flow of Process Chains using various tools and specifically the use of ABAP code to make logic decisions within a Process Chain.
As most of you will be aware we already have the ability to call ABAP programs in a process chain using the ABAP program process but there is no way to pass values or results from the ABAP process to the next step in the Process Chain short of causing the program to error or using events (both of which will be reviewed here).
On the other side of the coin we have the Decision process that can be used to determine which one of multiple branches of a process chain should be executed based on logic defined within a formula. The standard functions are the same as in a BW Transformation formula and allow you to base a decision on things such as date, string manipulation, mathematical operations and arguments from predecessor steps.
The problem is that, with the exception of values from a preceding step and system fields (those on the left), none of these functions allow an external argument and have to be hard coded within the formula code. There's also a question of how useful some of these functions are in this circumstance; while I'm sure that most of us have used Cosine at some point in our lives I've really struggled to think of a reason I'd use it in a Process Chain Decision.
Of the functions that allow external inputs there are a couple that I've found handy:
- SYST-DATUM - This is a system field to give the date. While it's not a function in itself it can be used with any of the DATE functions or string manipulation function (e.g. LEFT) to determine the day or month for your decision. Examples for this sort of functionality would be process chains that you only want to run at month end or year end.
- PREDECESSOR_PARAMETER (and PROCESS_PARAMETER) - These will return values from a previous process in the Process Chain based on the previous process's implementation of the interface IF_RSPC_GET_INFO. This can be used with a lot of the standard loading processes within a Process Chain (e.g. DTPs, Infopackages, Aggregation, Compression etc) to get additional information on the process.
On top of these you also have some other options to control the flow of a Process Chain using ABAP:
- Raise an exception - In your ABAP code you set the program to raise an exception if a set of criteria occur which would stop the chain. An example of this would be if you are checking for an incoming file but it cannot be found on the server location. This stops the process chain completely and no further processing is done.
- Raise an event - Events (managed in SM64) are triggers than can be used to start any Process Chain, Interrupt process or even background job with the specific event raised as a start parameter. They are easy to use but can also become overly complicated very quickly as there is no easy way to determine what Process Chains will be called by which event at any given time. A typical example of an event would be processing files where you don't know the number of files waiting to be processed. You might have a first chain that runs an ABAP program to check if there are any files and processes the first one it finds then raises an event to call the same Process Chain again (looping the chain for multiple files); as soon as no further files are found the program raises a second event that starts another Process Chain to do the rest of the propagation of data up to the reporting layer.
But what if you're decision isn't based on any of these? What if you're process involves checking the total number of records to load from several DTPs which are run in separate chains or you have one chain to load to the acquisition layer multiple times a day and then a single chain to load further downstream or you simply use an ABAP program to determine if a file has arrived, what sort of file it is and ultimately which target it should be loaded to?
In the following example the technical requirement is to decide whether or not to delete the indexes on a cube before a DTP load based on the number of records yet to be loaded. The reason we are using ABAP is because we cannot see how many records there are in the delta before the DTP starts to load and once the load is started we cannot delete the indexes. There are any number of discussions on whether and when it is best to delete indexes that I will not go into here. For arguments sake the threshold to delete the index is set at 1000 records; any less and the DTP will load with indexes in place, any more and we delete the indexes, load the DTP and then recreate the indexes.
Steps to create ABAP decision:
1) Using SE19 create a new implemenation of BAdI RSAR_CONNECTOR:
Give you implementation a name and enter the short text. In the Interface tab make a note of the implementing class name:
2) Save your implementation then using SE24 edit the implementing class:
Enter your new method here that will be where you put your ABAP code. The method should be Static and Public.
3) Click the Parameter button to enter the parameters of the method. Note that changing paramaters are not allowed (only importing, exporting and returning are valid) and only a single exporting or returning value is permitted.
4) Click on the Methods button then double click on the method name to enter the ABAP code:
5) Test, save and activate your method then come back to the main SE24 screen and activate the class.
6) Using SE19 edit your BAdI implementation
7) On the Interface tab double click on the GET method to edit the code. The code here allows the method we've just created to be seen in the formula screen in the Decision process:
The first part of the code (WHEN ' ') sets up a new category in the Functions drop down menu, the second part of the code adds the new method created to that new category.
8) Activate your code then activate the BadI. Note that when it is activated the Runtime Behaviour field will be set to "Implementation will be called".
9) Create/Modify Process Chain using RSA1 - Here we are creating a new process chain
Create a new Decision Process and enter a name and description
Edit the formula, enter a name and click ok. In the drop down menu on the function side you can now see "BW Custom Functions" and in there is our new function:
As you can see the formula has been entered and will return a number of records to be retrieved. The formula will be evaluated to determine whether it is true or false and return that true/false value.
Exit and save your Decision process. Note that in this example the Else section event has been changed to Option 2 rather than the default Error.
Now create the logic flow in the Process Chain:
The first step determines if the number of records is over 1000 in the next delta (Option 1). If so then it deletes the index and executes the DTP, if not (Option 2) then it just executes the DTP without deletion of indexes. The decision step is also used to determine if index creation is necessary and will do this once the DTP has completed it's load (AND step at the end).
First run (Delta has 865000 records):
Second run (Delta has 0 records):
To make this a more global solution I'd probably include a value in a parameter table for the threshold value and possibly have a default value with the option to specify thresholds for those loads that do not fit.
In conclusion this is just a simple example of how you can include ABAP within a Process Chain Decision process. I hope it helps.