Skip to main content
Do checkout my poem section. You are going to love it.

Event-Driven Background Jobs

Event-Driven Background Jobs in SAP BASIS

I. What are Event-Driven Jobs?

Event-driven background jobs are SAP background jobs whose execution is triggered not by a specific time or date, but by the occurrence of a predefined "event" within the SAP system or from an external source.

  • SAP Event: A named flag or signal that can be raised (triggered) within the SAP system or by an external program. When an event is raised, any background job configured to "wait for" that event will be set to Ready status and subsequently executed by an available background work process.
  • Purpose:
    • Automation & Dependencies: Automate complex process chains where one job's successful completion (or specific output) triggers another job.
    • Real-time Processing: React to real-time occurrences (e.g., file arrival, interface completion, critical data change).
    • Flexibility: Decouple job scheduling from fixed time windows, making processes more adaptable to varying data volumes or external system availability.
    • Integration: Allow external systems to initiate SAP processes without direct RFC calls to specific function modules, providing a robust and less tightly coupled integration point.

II. Defining and Managing Events (SM64)

SM64 (Business Event) is the central transaction for defining and managing SAP events.

  1. Defining an Event:

    • Go to SM64.
    • Click Create.
    • Event Name: Choose a meaningful name (e.g., Z_FILE_ARRIVED_AP, SAP_HR_DATA_LOAD_COMPLETE). Follow a consistent naming convention (e.g., Z_CLIENT_FUNCTION_EVENT).
    • Description: Provide a clear description of what the event signifies.
    • Parameter (Optional): Define an event parameter (e.g., &EVTPARM). This allows you to pass a short string value (up to 32 characters) along with the event. The triggered job's ABAP program can read this parameter.
      • Use Cases: Pass a file name, a unique ID, a status code, or a processing variant name.
    • Save the event.

  2. Monitoring Events in SM64:

    • SM64 displays a list of all defined events.
    • It shows the Last Creation Date and Last Creation Time for when the event was last triggered.
    • You can select an event and click Event History to see a log of its past triggers.

III. Scheduling Event-Driven Jobs (SM36)

  1. Create a New Background Job:
    • Go to SM36.
    • Enter Job Name and Job Class.
    • Define Job Steps (ABAP program, external command, etc.) as usual.
  2. Define Start Condition as After Event:
    • Click Start Condition.
    • Select the After Event radio button.
    • Event: Enter the name of the event you defined in SM64 (e.g., Z_FILE_ARRIVED_AP). Use F4 help to search.
    • Parameter (Optional): If the event is configured to pass a parameter, and your job's ABAP program needs to consume it, you can specify &EVTPARM here in SM36 to pass it to the job's variant.
    • Period Job (Optional): If you want the job to be re-released and wait for the event again after it finishes, check Period Job and specify a period (e.g., Daily). If not checked, the job will run once and then remain in Finished or Canceled status until manually re-released.
    • Save the start condition and the job. The job will now be in Released status, waiting for the event.

IV. Triggering Events (Raising an Event)

An event can be triggered in several ways:

  1. Manually (SM64):

    • Go to SM64.
    • Select the event.
    • Click Raise (or Trigger).
    • If the event has a parameter, you'll be prompted to enter the Event Parameter.
    • Use Case: Testing, one-off triggering.

  2. From an ABAP Program:

    • This is the most common method for intra-SAP process chaining.
    • Use the function module BP_EVENT_RAISE.
    • Syntax Example:
      ABAP
      CALL FUNCTION 'BP_EVENT_RAISE'
  EXPORTING
    eventid = 'Z_FILE_ARRIVED_AP'
    eventpar = 'MY_FILE.CSV'  " Optional parameter
  EXCEPTIONS
    OTHERS = 1.

IF sy-subrc <> 0.
  " Error handling
ENDIF.
    • Use Case: After a preceding background job finishes successfully, its last step calls BP_EVENT_RAISE to trigger the next job.

  3. From the Operating System (OS Command):

    • Allows external systems or OS scripts to trigger SAP events.
    • Uses the SAP executable btctrns1.
    • Syntax Example (UNIX/Linux):
      Bash
      /usr/sap/<SID>/SYS/exe/run/btctrns1 -t EVENT -E Z_FILE_ARRIVED_AP -P FILENAME_001.TXT
      • -t EVENT: Specifies event type.
      • -E <Event_Name>: The name of the event.
      • -P <Parameter_Value>: (Optional) The event parameter value.
    • Important: The OS user executing btctrns1 must have necessary permissions. btctrns1 connects to the SAP Gateway.
    • Use Case: An external script detects a new file, processes it, and then triggers an SAP job to import the data, passing the filename as a parameter.

  4. As a Background Job Step (using SM69 External Command):

    • You can define an external OS command in SM69 that calls btctrns1.
    • Then, use this SM69 command as a step in an ABAP background job.
    • Use Case: A preceding ABAP job prepares data, then triggers another ABAP job by raising an event via an OS command step. This is less common than directly using BP_EVENT_RAISE from ABAP, but possible.

V. Monitoring Event-Driven Jobs (SM37)

  • Status Changes: When an event is raised, a Released job waiting for that event will change its status to Ready, then to Running (if a background work process is available).
  • Checking Event Parameters: The event parameter passed can be seen in the Job Log of the triggered job (if the ABAP program logs it). You can also typically see it in SM37 under Job Details for After Event jobs.
  • Dependencies: When troubleshooting, ensure the event was actually raised (check SM64 history) and that the job's start condition correctly specified the event.

VI. Important Configuration and Best Practices

  1. Event Naming Convention:
    • Establish a clear, consistent, and unique naming convention for events (e.g., Z_<Module>_<Process>_<Status>, Z_FI_POSTING_COMPLETED, Z_HR_FILE_RECEIVED).
    • Avoid generic names like Z_EVENT1.
  2. Event Parameter Usage:
    • Design your ABAP programs to read and utilize the &EVTPARM value when necessary. Use function modules like BP_EVENT_READ or ensure the job variant uses &EVTPARM.
    • Ensure the external system or triggering program passes a meaningful value.
  3. Security for Event Triggering:
    • S_BTCH_EVT Authorization Object: The user triggering an event (via BP_EVENT_RAISE in ABAP or btctrns1 from OS) needs authorization for S_BTCH_EVT with ACTVT=01 (Create/Raise) and the specific EVENTID.
    • OS User Permissions: The OS user executing btctrns1 must have permissions to run the executable and connect to the SAP Gateway.
  4. Error Handling in Triggering Programs:
    • Programs that raise events should have robust error handling. If the event fails to raise (BP_EVENT_RAISE returns sy-subrc <> 0), it should be logged or alerted to prevent the dependent job from never starting.
  5. Monitoring and Alerting:
    • SM64 Event History: Regularly check SM64 event history to verify events are being triggered as expected.
    • Solution Manager / CCMS (RZ20): Configure alerts for dependent jobs that are stuck in Released status for too long, as this might indicate the event was not raised. Also, alert on canceled event-driven jobs.
    • Job Chaining/Dependency Monitoring: Tools like Solution Manager or custom developments can visualize and monitor complex event-driven job chains.
  6. Periodic Jobs for Event-Driven Chains:
    • If an event-driven job needs to run every time an event occurs, ensure it is configured as a Periodic Job in SM36 after After Event is selected. This makes it automatically re-release itself and wait for the next event trigger after it finishes. If not periodic, it will only run once.
  7. Resource Management:
    • Ensure sufficient background work processes are available for event-driven jobs, especially if a single event can trigger many jobs concurrently.

10 Interview Questions and Answers (One-Liner) for Event-Driven Background Jobs

  1. Q: What is the main transaction for defining and managing SAP events?
    • A: SM64.
  2. Q: How do you set a background job to wait for an event?
    • A: In SM36, set the Start Condition to After Event.
  3. Q: Which SAP function module is used to raise an event from an ABAP program?
    • A: BP_EVENT_RAISE.
  4. Q: What is the OS command line tool used to trigger an SAP event from the operating system?
    • A: btctrns1.
  5. Q: Can you pass a parameter with an event trigger?
    • A: Yes, using the Event Parameter field in SM64 or btctrns1 -P.
  6. Q: What authorization object is required to raise an event?
    • A: S_BTCH_EVT.
  7. Q: If an event-driven job needs to run multiple times, what setting in SM36 is crucial?
    • A: Mark it as a Period Job.
  8. Q: What status will an event-driven job be in while waiting for its event?
    • A: Released.
  9. Q: Where can you check when an event was last triggered?
    • A: In SM64, under Last Creation Date/Time or Event History.
  10. Q: Why use an event-driven job instead of an After Job job?
    • A: Events offer more flexibility, can be triggered from external systems, and decouple dependencies.

5 Scenario-Based Hard Questions and Answers for Event-Driven Background Jobs

  1. Scenario: You've implemented a critical daily process where an external ETL tool places a daily_sales.csv file on the SAP application server at //sap_app_server/interface/sales_in/. Once the file is placed, an SAP background job Z_SALES_IMPORTER (ABAP program Z_PROCESS_SALES_FILE) needs to be triggered immediately to process it. The Z_SALES_IMPORTER job needs the exact filename (which includes a timestamp, e.g., daily_sales_202506211030.csv) to be passed to it for processing.

    • Q: Detail the complete configuration and process, from defining the event to the external tool's action, to achieve this, ensuring the filename is passed correctly.
    • A:
      • I. Define the SAP Event (SM64):
        • Event Name: Z_SALES_FILE_ARRIVED
        • Description: "Triggered when new daily sales file arrives on SFTP server."
        • Parameter: &EVTPARM (this will carry the filename).
        • Save.
      • II. Configure the Background Job (SM36):
        • Job Name: Z_SALES_IMPORTER
        • Job Class: B (e.g., as it's critical daily processing)
        • Steps:
          • ABAP Program: Z_PROCESS_SALES_FILE
          • Variant: Create a variant (e.g., Z_VARIANT_DYNAMIC). Crucially, the ABAP program Z_PROCESS_SALES_FILE must be designed to read its input filename from a parameter passed to the variant, or from BP_EVENT_READ. For &EVTPARM, you define a selection screen parameter (e.g., P_FILENAME TYPE STRING) in the program's variant, and then in SM36 -> Step -> Variant, use &EVTPARM as the value for P_FILENAME.
        • Start Condition:
          • Select After Event.
          • Event: Z_SALES_FILE_ARRIVED
          • Parameter: &EVTPARM (This tells SAP to pass the parameter from the event to the job's variant/program).
          • Period Job: Check Period Job and set to Daily (or Immediate if the external tool is truly once per day, but Daily ensures it re-releases for the next day's file).
        • Save the job. It will be in Released status.
      • III. External ETL Tool Action (OS Level Command):
        • After the ETL tool successfully places the daily_sales_202506211030.csv file on //sap_app_server/interface/sales_in/, its final step should execute an OS command on the sap_app_server (or any server that can reach the SAP Gateway).
        • OS Command:
          Bash
          /usr/sap/<SID>/SYS/exe/run/btctrns1 -t EVENT -E Z_SALES_FILE_ARRIVED -P /interface/sales_in/daily_sales_202506211030.csv
          • Replace <SID> with your SAP System ID.
          • The value passed with -P (e.g., /interface/sales_in/daily_sales_202506211030.csv) becomes the Event Parameter.
        • OS User: The OS user executing this command must have permissions to run btctrns1 and connect to the SAP Gateway.
      • IV. ABAP Program Z_PROCESS_SALES_FILE Adaptation:
        • The ABAP program must be capable of reading the Event Parameter.
        • Option A (Recommended for &EVTPARM in variant):
          ABAP
          PARAMETERS: p_file TYPE string. " This parameter is in the job variant and takes &EVTPARM
START-OF-SELECTION.
  " p_file now contains '/interface/sales_in/daily_sales_202506211030.csv'
  " Proceed with file processing using p_file
        • Option B (If not using variant parameter):
          ABAP
          DATA: lv_event_param TYPE btceparam.
CALL FUNCTION 'BP_EVENT_READ'
  EXPORTING
    eventid = 'Z_SALES_FILE_ARRIVED'
  IMPORTING
    eventpar = lv_event_param
  EXCEPTIONS
    OTHERS = 1.
IF sy-subrc = 0.
  " lv_event_param contains the filename
  " Proceed with file processing using lv_event_param
ENDIF.
      • Process Flow: ETL places file -> ETL executes btctrns1 with filename -> btctrns1 triggers Z_SALES_FILE_ARRIVED event -> Z_SALES_IMPORTER (waiting for this event) is set to Ready and runs, receiving the filename as a parameter -> Z_PROCESS_SALES_FILE processes the specific file.

  2. Scenario: You have a complex financial closing process involving 10 jobs. Job_A runs, and upon successful completion, triggers Job_B and Job_C simultaneously. Once both Job_B and Job_C complete successfully, Job_D should start.

    • Q: Design an event-driven job chain in SAP to manage these dependencies, explaining the events and job configurations needed for each step, and how to ensure Job_D only starts after BOTH Job_B and Job_C are finished.
    • A:

      • Event Definitions (SM64):

        1. Z_JOB_A_FINISHED (No parameter) - Triggered by Job_A.
        2. Z_JOB_B_FINISHED (No parameter) - Triggered by Job_B.
        3. Z_JOB_C_FINISHED (No parameter) - Triggered by Job_C.
        4. Z_ALL_DEPENDENCIES_MET (No parameter) - This will be a virtual event triggered by a custom logic.

      • Job Configurations (SM36):

        • Job_A:

          • Start Condition: Immediate (or scheduled time/date).
          • Steps: Contains its relevant programs.
          • Last Step: An ABAP program (or a custom method) that, upon Job_A's successful completion, calls:
            ABAP
            CALL FUNCTION 'BP_EVENT_RAISE' EXPORTING eventid = 'Z_JOB_A_FINISHED'.
          • Period Job: No (unless Job_A is meant to run periodically and trigger the chain each time).

        • Job_B:

          • Start Condition: After Event -> Event: Z_JOB_A_FINISHED.
          • Steps: Contains its relevant programs.
          • Last Step: An ABAP program that, upon Job_B's successful completion, calls:
            ABAP
            CALL FUNCTION 'BP_EVENT_RAISE' EXPORTING eventid = 'Z_JOB_B_FINISHED'.
          • Period Job: Yes (to re-release after execution, ready for the next Z_JOB_A_FINISHED).

        • Job_C:

          • Start Condition: After Event -> Event: Z_JOB_A_FINISHED.
          • Steps: Contains its relevant programs.
          • Last Step: An ABAP program that, upon Job_C's successful completion, calls:
            ABAP
            CALL FUNCTION 'BP_EVENT_RAISE' EXPORTING eventid = 'Z_JOB_C_FINISHED'.
          • Period Job: Yes (to re-release after execution, ready for the next Z_JOB_A_FINISHED).

        • Job_D:

          • Start Condition: After Event -> Event: Z_ALL_DEPENDENCIES_MET.
          • Steps: Contains its relevant programs.
          • Period Job: Yes.

      • Ensuring Job_D Starts After BOTH Job_B and Job_C (The "AND" Condition):

        • SAP's standard event-driven jobs support an "OR" condition (if Job_X waits for Event_Y OR Event_Z, it triggers when either occurs). For an "AND" condition, you need a monitoring job or a custom ABAP program.
        • Recommended Solution: A Dedicated "Event Monitor" ABAP Job:
          1. Create a New Job: Z_EVENT_MONITOR_B_C
          2. Start Condition: After Event -> Event: Z_JOB_B_FINISHED.
          3. Period Job: Yes.
          4. Steps: This job will run an ABAP program (e.g., Z_CHECK_B_C_EVENTS) that performs the "AND" logic.
          5. Z_CHECK_B_C_EVENTS Program Logic:
            • When Z_EVENT_MONITOR_B_C is triggered by Z_JOB_B_FINISHED, the program Z_CHECK_B_C_EVENTS will then check if Z_JOB_C_FINISHED has also occurred recently.
            • This can be done by checking the SM64 event history for Z_JOB_C_FINISHED (e.g., within the last few minutes/hours).
            • If both conditions are met (i.e., Z_JOB_B_FINISHED and Z_JOB_C_FINISHED have recently occurred):
              ABAP
              CALL FUNCTION 'BP_EVENT_RAISE' EXPORTING eventid = 'Z_ALL_DEPENDENCIES_MET'.
            • Else (if Z_JOB_C_FINISHED has not occurred yet): The program logs that it's waiting and exits. This Z_EVENT_MONITOR_B_C job will then be re-released (because it's periodic) and wait for the next trigger of Z_JOB_B_FINISHED (which may happen again, or not, until Job_A runs again).
        • Alternative for Z_EVENT_MONITOR_B_C (more robust, but complex): Make Z_EVENT_MONITOR_B_C wait for Z_JOB_C_FINISHED instead, and its program checks for Z_JOB_B_FINISHED. The key is that one of them needs to be the direct trigger, and the program performs the check for the other. This scenario is why tools like SAP Solution Manager's Business Process Monitoring are preferred for complex chains.

  3. Scenario: A background job Z_EXT_REPORT needs to be triggered by an external monitoring system via btctrns1. The Job Log of Z_EXT_REPORT consistently shows "Job started... Job canceled" with no other messages or ST22 dump. SM21 shows CPIC-CALL: 'ThSAPRcvEx' : cmRc=20 thRc=456#Error in program call.

    • Q: What does the thRc=456 error specifically indicate in this context, and what detailed steps would you take, involving OS-level checks and SAP Gateway monitoring, to troubleshoot and resolve this issue?
    • A:
      • thRc=456 Indication: thRc=456 (often TP_NOT_FOUND or PROGRAM_NOT_REGISTERED) in the CPIC-CALL error when using btctrns1 to trigger an event, specifically means that the SAP Gateway could not find or execute the btctrns1 program itself, or the connection from btctrns1 to the Gateway failed due to a fundamental environment issue on the OS level. This is not an issue with the event itself or the job, but with the btctrns1 executable.
      • Detailed Troubleshooting & Resolution Steps:
        1. Verify btctrns1 Path and Permissions on OS:
          • Action: Log into the OS of the external monitoring system (or wherever btctrns1 is being executed from).
          • Action: Check the exact path to btctrns1 in the external system's script (e.g., /usr/sap/<SID>/SYS/exe/run/btctrns1). Is this path correct and accessible?
          • Action: Verify the OS user that runs the external monitoring system's script has execute permissions on btctrns1. (chmod +x btctrns1 if needed, but it should have correct permissions after SAP installation).
          • Rationale: The most common cause of thRc=456 in this scenario.
        2. Manual Execution of btctrns1 on OS:
          • Action: As the exact OS user that the external system uses, manually execute the btctrns1 command from the command line:
            Bash
            /usr/sap/<SID>/SYS/exe/run/btctrns1 -t EVENT -E Z_EXT_TRIGGER -P TEST_PARAM
          • Observe: Does it return any specific errors on the command line? (e.g., "command not found", "permission denied", "connect failed"). This output is often more informative than the SM21 log.
          • Rationale: Direct reproduction helps isolate the problem to the OS level.
        3. SAP Gateway Connectivity Check (ping, telnet):
          • Action: From the external system's OS, try to ping the SAP application server's IP address (where the Gateway is running).
          • Action: Try to telnet to the SAP Gateway port (e.g., telnet <SAP_APP_SERVER_IP> 3300 for instance 00, or 3301 for 01, etc.). A successful connection means the port is open.
          • Rationale: Rule out network connectivity issues or firewall blocks.
        4. SAP Gateway Monitoring (SMGW):
          • Action: On the SAP system, go to SMGW (Gateway Monitor).
          • Check: See if there are any errors in the Gateway log (GoTo -> Log -> Display).
          • Check: Look for any blocked connections or security errors.
          • Rationale: While the error points to btctrns1 itself, the Gateway might log connection attempts and failures.
        5. dev_w* Traces on SAP Application Server:
          • Action: On the SAP application server, check the dev_w* developer traces (work directory) for the work processes (dpmon also gives clues) around the time of the event trigger attempt. These logs might contain more detailed information from the SAP kernel regarding the failed btctrns1 connection.
          • Rationale: Kernel-level debugging logs.
        6. Solution:
          • Most likely, the fix will involve correcting the path to btctrns1, ensuring the OS user has sufficient permissions to execute it, or resolving network/firewall issues preventing connection to the SAP Gateway.
          • Once btctrns1 can successfully trigger an event from the OS command line, the SAP job should begin to run.

  4. Scenario: A weekly financial reconciliation job (Z_WEEKLY_RECON) is triggered by an event Z_RECON_DATA_READY. This job is set as a Period Job in SM36. However, after running successfully once, it never gets triggered again the following week, remaining in Finished status, even though the Z_RECON_DATA_READY event is confirmed to be raised weekly by a preceding process.

    • Q: What is the most common reason for a periodic event-driven job failing to re-release, and how would you verify and rectify this?
    • A:
      • Most Common Reason: The most common reason for a periodic event-driven job not re-releasing is that the "Period Job" flag in SM36 was not actually checked or was somehow unset during a change to the job. If it's not a periodic job, it runs once, sets to Finished, and is done. It won't wait for the event again.
      • Verification and Rectification Steps:
        1. Verify Period Job Flag in SM37 / SM36:
          • Action: Go to SM37. Find Z_WEEKLY_RECON and view its details.
          • Check: In the Job Details -> Start Condition tab, confirm if the Period Job checkbox is actually ticked.
          • Action: If it's not ticked, go to SM36. Select Z_WEEKLY_RECON. Click Change. Go to Start Condition. Tick Period Job. Set the appropriate periodic value (e.g., Weekly). Save.
          • Rationale: This is the primary culprit. Even if you thought you set it, a mistake or an overwrite could have occurred.
        2. Review Job Change History:
          • Action: In SM37, select Z_WEEKLY_RECON. Go to Job -> Job History (or Utilities -> Log -> Changes).
          • Check: Look for any recent changes to the job definition, especially modifications to the Start Condition. Identify who made the change and when.
          • Rationale: This can confirm if someone inadvertently unset the Period Job flag.
        3. Confirm Event Raising (SM64):
          • Action: While the scenario states the event is confirmed to be raised, it's always good practice to double-check SM64 for Z_RECON_DATA_READY. View Event History and confirm it was indeed raised at the expected time each week, with the correct parameters (if any).
          • Rationale: Rule out any miscommunication or intermittent failure of the event-raising mechanism.
        4. Work Process Availability (Less Likely, but for completeness):
          • Action: If the Period Job flag was correctly set, then the job should re-release. If it still doesn't, it's very rare but could indicate a system-level issue preventing the scheduler from re-releasing the job. Check SM21 and SM50/SM66 for any scheduler or work process issues around the time the job should have re-released.
          • Rationale: To cover all bases.
        5. Rectification: Once the Period Job flag is correctly set and saved, the job will typically re-release itself immediately (if the event was just raised) or wait for the next occurrence of Z_RECON_DATA_READY.

  5. Scenario: You need to implement a data load process where a master data extract job (Z_MASTER_EXTRACT) runs on APPSERV_01 and, upon its successful completion, triggers a dependent job (Z_DELTA_LOAD) on APPSERV_02. Both jobs should be triggered by an event, and the Z_DELTA_LOAD job should receive the extraction date as a parameter.

    • Q: Design this event-driven process. Explain the specific event type, job scheduling (including target server considerations), and how the extraction date is passed, considering the cross-server dependency.
    • A:

      • I. Event Definition (SM64):

        • Event Name: Z_MASTER_DATA_EXTRACTED
        • Description: "Master data extraction complete, triggers delta load."
        • Parameter: &EVTPARM (this will carry the extraction date).
        • Save.

      • II. Z_MASTER_EXTRACT Job Configuration (SM36 - on APPSERV_01):

        • Job Name: Z_MASTER_EXTRACT
        • Job Class: B
        • Target Server: APPSERV_01 (explicitly set to ensure it runs here).
        • Start Condition: Scheduled (Immediate or specific date/time).
        • Steps:
          • Step 1: Program for master data extraction.
          • Step 2 (ABAP Program): A simple ABAP program (e.g., Z_TRIGGER_DELTA_EVENT) that runs after Step 1.
            • Logic in Z_TRIGGER_DELTA_EVENT:
              ABAP
              DATA: lv_extraction_date TYPE sy-datum.
lv_extraction_date = sy-datum. " Or get from a previous step's output/variable

CALL FUNCTION 'BP_EVENT_RAISE'
  EXPORTING
    eventid = 'Z_MASTER_DATA_EXTRACTED'
    eventpar = lv_extraction_date " Pass current date as parameter
  EXCEPTIONS
    OTHERS = 1.
IF sy-subrc <> 0.
  " Log error: Failed to raise event
  MESSAGE 'Failed to raise event Z_MASTER_DATA_EXTRACTED' TYPE 'E'.
ENDIF.
        • Period Job: No (unless the master extract itself runs periodically and initiates the chain).
        • Save.

      • III. Z_DELTA_LOAD Job Configuration (SM36 - can be defined on any server, will run on APPSERV_02):

        • Job Name: Z_DELTA_LOAD
        • Job Class: B
        • Target Server: APPSERV_02 (Crucial for cross-server execution). This ensures that even though the event is global, this specific job instance is scheduled to run only on APPSERV_02.
        • Start Condition:
          • Select After Event.
          • Event: Z_MASTER_DATA_EXTRACTED
          • Parameter: &EVTPARM (This tells SAP to take the parameter passed with the event and make it available to the job's program/variant).
          • Period Job: Check Period Job and set to Daily (if the process runs daily and needs to re-release).
        • Steps:
          • Step 1: ABAP program (Z_PROCESS_DELTA_DATA).
          • Variant: The Z_PROCESS_DELTA_DATA program's variant should have a selection parameter (e.g., P_EXTR_DATE TYPE SY-DATUM) configured to accept &EVTPARM.
          • Logic in Z_PROCESS_DELTA_DATA:
            ABAP
            PARAMETERS: p_extr_date TYPE sy-datum. " This parameter is in the job variant and takes &EVTPARM

START-OF-SELECTION.
  " p_extr_date now contains the date from Z_MASTER_EXTRACT
  " Use p_extr_date for delta logic (e.g., selecting data from this date onwards)
  MESSAGE i000(00) WITH 'Processing delta for extraction date:' p_extr_date.
  " ... rest of the delta load logic ...
        • Save.

      • Process Flow & Cross-Server Aspect:

        1. Z_MASTER_EXTRACT starts on APPSERV_01.
        2. Upon completion, its last step on APPSERV_01 calls BP_EVENT_RAISE to trigger the Z_MASTER_DATA_EXTRACTED event, passing the extraction date.
        3. The SAP scheduler (which runs globally) detects that Z_MASTER_DATA_EXTRACTED has been raised.
        4. Z_DELTA_LOAD, which is waiting for this event and has APPSERV_02 as its target server, is activated.
        5. The scheduler assigns Z_DELTA_LOAD to an available background work process on APPSERV_02.
        6. Z_DELTA_LOAD executes on APPSERV_02, and its program Z_PROCESS_DELTA_DATA receives the extraction date via &EVTPARM and processes the delta.

This setup effectively manages the cross-server dependency and passes critical information using the event mechanism.

Comments

Post a Comment

Popular posts from this blog

An experiment with the life

"Best Thing about experiment is that it only improves the outcome." Well, I am Rakshit, hope you already know. I am not special and surely not especially gifted. Neither things go according to my wish. Neither I am the best writer.  But I am myself who is totally unique from anyone else. And I am Rakshit Ranjan Singh. I have my own fun, fights and fall in the most fundamentalistic way. Mechanical is my degree. IT is my Job. Beauty in nature is what I search. Words of my heart are what I write. Four different things I carry on my shoulder and a smile on my face, hope you might have seen that. What do I care for? Family, friends and nature. Do I have regrets? More than I can imagine. Let us move further to see what really is my life.
Read more

Learn Java

Hello Friends, You might already know what Java is. Without taking much of your time, I would like to ask you to please click below if you are ready to learn it from end to end. The Material over here is available on the internet and is free to access.  I would request you to bookmark this page and follow it. Please comment if you are happy with the learning. click here
Post a Comment
Read more

Driving

My Driving Journey: From Zero to (Almost) Hero! Hello everyone! I'm excited to share my ongoing adventure of learning to drive. It's been a mix of nervous excitement, hilarious near-misses, and the slow but steady feeling of progress. Buckle up, because here's a peek into my journey behind the wheel! The First Lesson: Clutch Confusion! My first time in the driver's seat was... memorable. Let's just say the clutch and I weren't immediate friends. Lots of jerky starts and a few stalls later, I began to understand the delicate dance between the pedals. My instructor was incredibly patient (thank goodness!). Mastering the Steering Wheel (Sort Of) Steering seemed straightforward enough, but navigating turns smoothly was a different story. I definitely had a few moments of feeling like I was wrestling with the wheel. Slowly but...
Post a Comment
Read more