If a large number of products exist in the selected plans in SAP CRM, the update in SAP NetWeaver BW can take too long and time out. When this timeout occurs, the RFC connection breaks, but the calling program in SAP CRM continues to wait for the signal to continue processing. It’s now likely that the data between SAP CRM and SAP NetWeaver BW is going to be inconsistent.

To prevent a timeout, you can split your processing to execute four distinct, independent, but connected events, which I will expand on:

• Select all the promotions and determine the products to update
• Call SAP NetWeaver BW to update the volume forecast
• Signal completion of the update in SAP CRM
• Update the promotions once the volume forecast is done. You do this by converting the promotion update logic into a second batch job that is executed after the volume forecast is completed.

Steps to Decouple Processing and Split the Original Batch Program

Step 1. Create a background processing event. When several batch jobs are scheduled to run in sequence, the next batch job in line waits for an end-of-job event that is raised when the previous job completes. You can do something similar by creating a new event that your custom program raises. To do this, enter transaction SM62 and click the BckProcEvnts tab (Figure 1).

Figure 1

Navigate to the BckProcEvnts tab

Next, click the create icon and the pop-up dialog in Figure 2 appears. Enter an event name and description and then click the Save button. Take care not to select the System check box — this is the event that you raise later in your programming.

Figure 2

New event creation

Step 2. You can raise the background processing event you created in step 1 using the function module BP_EVENT_RAISE (or from SAP CRM 7.0, use the syntax CL_BATCH_EVENT->RAISE to call the class within a program). Unfortunately, neither this function module nor the class method is remote enabled. You need a remote-enabled call because the calling program executes in SAP NetWeaver BW. To get around this difficulty, create a wrapper function module that uses the identical signature but is remote-enabled (Figure 3). To create the function module, use transaction SE37 or the ABAP Workbench (transaction SE80). You first need to create a function group (unless you already have a utilities function group that you want to use) and then create a specific function module within the group.

Figure 3

Attributes screen of the function module

The wrapper function should have the same signature (e.g., imports, exports, changing, tables, and exceptions) as the BP_EVENT_RAISE function module. Make a copy of the function module signature and select Remote-Enabled Module on the Attributes screen. The class method should have the same signature in SAP CRM 7.0 as well.

Once you have set up the signature of the wrapper function, enter the source code to call the BP_EVENT_RAISE function module. Note that the parameters of the wrapper function module are the same as the BP_EVENT_RAISE function module. Figure 4 is a view of the Source code tab after you have completed your coding using the class method.

Figure 4

Source code tab — note that the signatures (e.g., the exporting and exception parameters) are the same

The EVENTID is the event that you created in step 1. EVENTPARM can be a value that you pass over to SAP NetWeaver BW when your initial program makes the RFC call to begin the SAP NetWeaver BW update processing. You must code your SAP NetWeaver BW program with this event parameter (even though it is not needed for the update) so that you have it at the end of the SAP NetWeaver BW processing to use when you raise the event in SAP CRM (which I explain later in this article). Using the EVENTPARM parameter enables multiple versions of the batch job to run in parallel without releasing an incorrect follow-up job.

Step 3. Now that you have created the means to start a scheduled job, you need to change your coding. First, split your original batch job in two. The first batch job:

• Does the initial selection processing
• Schedules the second batch job so that it begins execution on event EVENTID with event parameter EVENTPARM
• Performs an RFC to SAP NetWeaver BW to perform the SAP NetWeaver BW update

This sequencing is important. If you trigger the SAP NetWeaver BW job before scheduling the second SAP CRM job, it is possible that the SAP NetWeaver BW job will finish before the second batch job is even scheduled. If that occurs, the second job never receives the signal to start processing and none of the promotions that were initially selected are processed. The second batch job has the rest of the processing logic from the original program that was written to update the promotions.

When you create this second batch job, include a selection screen that contains all of the parameters from the original batch job that are needed to perform the update processing. In addition, add a select range parameter that you use to load the list of promotions that you wish to update. The first processing step of the second batch job is to unpack the parameters passed into the program to put the list of promotions into an internal table. From that point, the processing can continue as written in the original program before the program was split.

Step 4. Schedule a batch job from within a program. This is a four-step process:

• Fill the parameters to use in the batch job
• Call function JOB_INIT to get a job number and then set a variable with a job name (this name cannot have spaces)
• Perform a SUBMIT JOB (including the parameter settings)
• Call function JOB_CLOSE. The JOB_CLOSE function is executed with the EVENT_ID = EVENTID and EVENT_PARAM = EVENTPARM needed for the job to start (Figure 5).

Figure 5

Call used to release the second batch job

When you execute the JOB_CLOSE function in the first batch program, fill in the exporting parameters as shown in Figure 5. Prior to this function call, you need to code your program to fill the four variables shown in the call with the appropriate values.

Step 5. The RFC to SAP NetWeaver BW is also a bit customized because you want it to return processing to the calling system and not keep the connection open. You do this by making it a wrapper function that contains all the processing parameters needed for the SAP NetWeaver BW update, as well as the event ID and event parameter that you need to use to start the second batch job.

Write a program that calls the update function and have the wrapper function submit the program as a batch job and return. This completes the function processing and returns control to the original program, which then finishes. On the SAP NetWeaver BW side, the submitted program logic should first perform the SAP NetWeaver BW update and then, when completed, perform the RFC back to SAP CRM to start the second batch job (Figure 6). The values for the three variables shown in Figure 6 (logsys, eventid, and lv_eventparm) were all passed to this program from the wrapper function module that was called from SAP CRM.

Figure 6

Call back to SAP CRM

When the job finishes successfully, the last step is the RFC call back to SAP CRM to start the process again using the eventid passed in the first place.

To summarize, the original processing consisted of a batch program in SAP CRM that selected promotions to determine which products to update and an RFC to SAP NetWeaver BW that executed an update planning function. When completed, processing control was returned to the waiting SAP CRM program. Once processing control returned to SAP CRM, the batch program continued by updating all of the selected promotions. To decouple the update activities and protect against a timeout, the original program and RFC were converted to three programs and two RFCs. The processing logic then became: 

• Select promotions
• Schedule a promotion update to execute when the SAP NetWeaver BW update is finished (second batch program)
• Call SAP NetWeaver BW with an RFC that submits an SAP NetWeaver BW update program (third batch program)
• Update SAP NetWeaver BW. When finished, call SAP CRM and raise the event that will start the waiting batch program.
• Update promotions

Using this logic, the updates are decoupled but still connected and dependent, and the risk of an RFC timeout is eliminated.

Michael Debevec

Michael Debevec is president of Debevec Consulting, Inc., and is a senior consultant with more than 14 years of experience with SAP. He has worked with SAP CRM for the past nine years and assisted in implementations in the high tech, consumer products, and pharmaceuticals industries. Prior to working in SAP, Michael was an IS manager in charge of logistics systems.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.