Installation

Five steps. Usually less than a day.

Enabling GUARD on a new Business Object is a one-time job for a developer. After that, every new rule is configuration — and the developer can step away. Here's exactly what those first hours look like.

1 Step DEVELOPER

Find a place to fire GUARD before SAVE

Spot the moment in the transaction where the SAVE happens.

The developer scans the transaction (or report, or custom application) to find the point in the standard SAP toolkit where GUARD can plug in. Any of the four candidates below will do — the common requirement is that the rule must run before the SAVE commits, must have access to the changed tables, and must be allowed to abort the SAVE.

BADI

Business Add-In implementations — most modern SAP BOs expose a *_BEFORE_SAVE filter implementation that's perfect for GUARD.

USER-EXIT

Classic includes that ship with the standard programs — the go-to insertion point in older transactions and SD/MM modules.

CUSTOMER-EXIT

CMOD / SMOD enhancement projects. When a transaction has a customer-exit before SAVE, GUARD slots straight in.

Custom code

Any line in a custom transaction, custom function module, or custom application — wherever your code already runs before the SAVE.

The insertion point must

  • fire before the SAVE commits to the database
  • have access to the tables that hold the change data
  • be allowed to abort the SAVE if a check fails
2 Step DEVELOPER

List every table that gets edited

Identify the tables the transaction actually changes.

The developer runs the transaction in debug or skims the source code and writes down every table that gets modified — header, items, parties, conditions, partner functions, anything that ends up touched. Those tables become the Inbound Data Sources GUARD will check against.

Below is the list for a contract maintained through ME31K / ME32K — a typical example.

Inbound Data Source · Object CONTRACT
  • EKKOPurchasing document — header
  • EKPOPurchasing document — items
  • EKPAPartner roles per document
  • EKKNAccount assignment per item
  • KONPConditions (item-level)
  • KONHConditions (header-level)
  • SYSystem data (for SY-UNAME, SY-LANGU filters)

Where header-and-item data must be checked together (e.g. EKKO ⇄ EKPO, EINA ⇄ EINE), the developer can register a combined Data Source so OSQL queries can join them in a single statement.

3 Step DEVELOPER

Six lines of ABAP

Hand the tables to GUARD and call EXECUTE.

The developer instantiates the BO-specific child of ZCL_GUARD, calls ADD_TABLE_ENTRY for each Data Source, then EXECUTE. The framework returns the messages and an error flag — the developer just needs to abort the SAVE if any errors came back.

ZCL_GUARD_ME_PROCESS_OUT · BAdI implementation 
"--- Inside the BEFORE-SAVE BAdI ----------------------------------
DATA(lo_guard) = NEW zcl_guard_contract(
                  iv_object_key = |{ ls_ekko-ebeln }| ).

lo_guard->add_table_entry( iv_tname = 'EKKO' i_data = VALUE tt_ekko( ( ls_ekko ) ) ).
lo_guard->add_table_entry( iv_tname = 'EKPO' i_data = lt_ekpo ).
lo_guard->add_table_entry( iv_tname = 'EKPA' i_data = lt_ekpa ).
lo_guard->add_table_entry( iv_tname = 'EKKN' i_data = lt_ekkn ).
lo_guard->add_table_entry( iv_tname = 'KONP' i_data = lt_konp ).

lo_guard->execute(
  IMPORTING
    et_msg_bapi = DATA(lt_msg)
    et_msg_bal  = DATA(lt_bal_msg) ).

"--- Stop SAVE if any error came back ------------------------------
IF line_exists( lt_msg[ type = 'E' ] ).
  ct_messages = lt_msg.
  RAISE EXCEPTION TYPE cx_im_save_error.
ENDIF.

That's the entire integration. The class ZCL_GUARD_CONTRACT is one short subclass of ZCL_GUARD the developer creates once for the BO. Every future rule lives outside this code.

4 Step DEVELOPER

Register the Object once · transaction ZGUARD_SET

Tell GUARD what the Object looks like.

Open ZGUARD_SET and create an Object record matching the BO. Then list the Inbound Data Source tables the code passes in — the same names from Step 2. Only the developer can do this step, because the developer is the one who decides which tables are exposed.

That's the last thing the developer has to do here. Everything after this is a functional task.

GUARD: Settings — Display ZGUARD_SET
Object CONTRACT
Description Purchasing Contract (ME31K / ME32K)
Active X
Test program ZGUARDR_OBJECT_CONTRACT_TEST
Inbound Data Source
Table name DB table Description
EKKOEKKOPurchasing document — header
EKPOEKPOPurchasing document — items
EKPAEKPAPartner roles
EKKNEKKNAccount assignment
KONPKONPConditions (item)
KONHKONHConditions (header)
SY(virtual)System data — for SY-UNAME filters
5 Step FUNCTIONAL

From here on, every new rule is configuration

The developer steps away. The framework is open for business.

The Business Object is now GUARD-ready. Functional consultants, business users, and analysts open ZGUARD_CONF and start adding Projects, Rules, Filters, Steps, Conditions, and Messages — using the Data Sources the developer registered. The developer can be on a different team, in a different country, or out for the week. None of that blocks the next rule.

Developer · one-time

The hard part — done.

A few hours, once per Business Object

  • Find the BAdI / USER-EXIT / CUSTOMER-EXIT / custom-code spot
  • List the tables the transaction edits
  • Subclass ZCL_GUARD, feed the tables, call EXECUTE
  • Register the Object in ZGUARD_SET
Functional · forever

Every new rule from now on.

No development ticket required

  • Create a Project for the product or team
  • Add Rules with Filters, Steps, Conditions, Messages
  • Build Decision Tables and OSQL queries on the fly
  • Activate / deactivate rules per environment
  • Switch a message between Error / Warning / Info
  • Transport — or export to a file and load directly in PRD
Total developer time per Business Object: typically half a day to one day, including testing. Time per new rule afterwards: minutes — by anyone with SAP technical literacy.

Set it up once. Use it forever.

One developer, one afternoon, and your Business Object is permanently open to configurable checks — across every project, every team, every environment.

See real situations → Back to overview