Skip to main content

Chapter 3: PDC Processing Orchestrator

In the previous chapter, we built a fantastic interactive workspace—an ALV grid where users can see financial data, select items with checkboxes, and click a "Post" button. But what happens after that click? Who takes the user's request and makes sure everything happens in the right order?

The Problem: A Factory with No Manager​

Imagine a factory with specialized workers. One worker fetches raw materials, another operates a machine, and a third packages the final product. If they all start working randomly without any coordination, you'll get chaos. The packaging worker might be waiting for a product that hasn't even been made yet!

Our application is like this factory. We have "workers" (pieces of code) that can:

  1. Fetch data from the database.
  2. Display that data in a grid.
  3. Post a financial document.
  4. Reverse another document.

We need a general manager to direct these workers, tell them when to start, and ensure the entire process runs smoothly from beginning to end. This manager is our PDC Processing Orchestrator.

The Solution: The General Manager (zcl_bseg_data_processor)​

In our project, the orchestrator is an ABAP Class named zcl_bseg_data_processor. Think of it as the brain of the operation. It doesn't do the heavy lifting itself, but it knows the entire plan and gives orders to the specialized workers (which are methods within the class).

The Orchestrator's main job is to manage the sequence of events. When our program starts, it immediately hires this manager and tells it to get to work.

* File: ZRE_FI_NOTED_ITEMS_POSTING.abap

START-OF-SELECTION.
  CREATE OBJECT go_data. " Create our Orchestrator 'go_data'

  " ... code to tell the orchestrator if we're working with Customers or Vendors ...

  go_data->main( ). " Tell the Orchestrator to start its main process

This simple go_data->main( ) call is like the factory owner telling the general manager, "Okay, start the day's work!"

The Orchestrator's Two Main Jobs​

Our manager has two primary responsibilities, handled by two key methods:

  1. main(): The initial setup. Get everything ready and show it to the user.
  2. process(): The action step. Respond to the user's "Post" command.

Job 1: The Initial Setup (main method)​

The main method is the first thing the orchestrator does. It follows a clear, logical plan:

  1. Order Data: Tell the data retrieval specialist to go find the noted items.
  2. Check the Results: Did the specialist find anything?
  3. Display or Stop:
    • If yes, tell the ALV specialist to display the data in our interactive grid.
    • If no, report that nothing was found and stop the process.

Here's how that plan looks in simplified code:

* Inside class ZCL_BSEG_DATA_PROCESSOR

METHOD main.
  DATA: lt_found_data TYPE tt_bseg_data. " A table for the results

  " Step 1: Tell the specialist to get the data
  get_bseg_data(
    IMPORTING
      et_cust1 = lt_found_data " Put the results here
  ).

  " Step 2: Check if any data was returned
  IF lt_found_data IS INITIAL.
    MESSAGE 'No data found for given selection' TYPE 'S'.
    RETURN. " Stop everything
  ENDIF.

  " Step 3: Tell the specialist to display the grid
  display_alv( it_data = lt_found_data ).
ENDMETHOD.

This ensures we never show an empty, useless grid to the user. The manager makes a smart decision first.

Job 2: Processing the User's Request (process method)​

This method springs into action when the user clicks the "Post" button in the ALV. The ALV event handler acts as a messenger, running to the manager and saying, "The user wants to post these selected items!"

The process method then follows its action plan:

  1. Get the List: Look at the data grid and identify every single row the user checked.
  2. Process One by One: Go through the selected items, one at a time.
  3. Delegate Tasks: For each item, give two commands in sequence:
    • First, tell the posting specialist to create the main financial document.
    • Second, tell the reversal specialist to automatically reverse the original noted item.

Here is the simplified code for the action plan:

* Inside class ZCL_BSEG_DATA_PROCESSOR

METHOD process.
  " Step 1 & 2: Loop through all rows that have their 'sel' checkbox ticked
  LOOP AT gt_log ASSIGNING FIELD-SYMBOL(<fs>) WHERE sel = 'X'.

    " Step 3a: Call the posting specialist
    post_fi_document(
       CHANGING
         is_cust1 = <fs> " Pass the current item to be posted
    ).

    " ... more logic happens here ...
  ENDLOOP.
ENDMETHOD.
  • LOOP AT gt_log...: This is the manager walking down the assembly line, looking only at the items marked for processing.
  • post_fi_document(...): This is the command to the posting worker. We'll examine this worker in detail in the Financial Document Posting Engine chapter.
  • The reverse_doc method (not shown above for simplicity) is called right after a successful post. We will cover this in the Automated Document Reversal chapter.

Under the Hood: The Flow of Commands​

Let's visualize the entire process flow, from the moment the program starts to the moment the user sees the data.

As you can see, the Orchestrator sits in the middle, coordinating everything. It takes the initial command from the main program and then directs the other components in the correct sequence to get the job done. It maintains the state of the application—it holds the data (gt_log) and ensures each step is completed before the next one begins.

Conclusion​

You've now met the general manager of our application! The PDC Processing Orchestrator (zcl_bseg_data_processor) is the central class that brings order to the chaos. It doesn't perform the individual tasks, but it's arguably the most important piece because it ensures the entire business process happens correctly and in the right order.

We learned that the orchestrator:

  • Is started by the main program at START-OF-SELECTION.
  • Uses its main method to coordinate the initial data fetching and display.
  • Uses its process method to handle the user's "Post" command, coordinating the posting and reversal of documents.
  • Acts as the central controller, holding the application's data and directing specialized "worker" methods.

So far, we've mentioned that the orchestrator tells a specialist to get the data. But how does that specialist actually find the right information in the database? Let's go meet that worker in the next chapter: Noted Item Data Retrieval.