Inside the app

A tour of the configuration screens.

Every screen in ZGUARD_SET / ZGUARD_CONF shows the same Dialog Structure on the left and a single editable list on the right. The examples below use a real ARTICLE MGMT project on the ARTICLE object.

1 Screen PROJECTS

Object → Projects · the entry point of the configuration

One Dialog Structure on the left, one list on the right.

The Dialog Structure on the left is the same tree on every screen — Objects, Projects, and the four parts of a Rule. Click an item, the right pane shows that list. Here: Projects for the ARTICLE object — a single project called ARTICLE MGMT.

‹ SAP Display View "Projects": Overview

▾📁Objects

📁Inbound Data Source

▾📂Projects

📁Notif. Emails
▾📁Custom Data Source

📁Fields

▾📁Decision Tables

📁Fields

📁Functions
📁OSQL Query
▾📁Rules

📁Filters
📁Check Steps
📁Conditions
📁Messages

Object: ARTICLE ⊞

Projects

	Project	Active	Stop Error	NoTechMSG
	`ARTICLE MGMT`

Screen 1 — ZGUARD_SET, Projects view. Three flags govern this project: Active, Stop Error (whether a configuration error stops the SAVE), and NoTechMSG (suppress framework-level technical messages).

2 Screen INBOUND DATA SOURCE

Objects → Inbound Data Source · maintained by developer

The tables the BAdI wiring code feeds in.

Everything GUARD's checks see comes from this list — the data the user is editing in the current session. For the ARTICLE object, the BAdI passes the master tables in scope: MARA, MARC, MAKT, MVKE, and so on. SY is the system row, used by filters that key off SY-UNAME / SY-DATUM.

Anything that isn't on this list — existing rows already on the database, lookup tables, custom Z-tables — has to be pulled in via an OSQL query or a Custom Data Source, which we'll see in the next screen.

‹ SAP Display View "Inbound Data Source": Overview

Object: ARTICLE ⊞

Inbound Data Source

	Table Name	Table Name in DB
	`MAKT`	`MAKT`
	`MAMT`	`MAMT`
	`MARA`	`MARA_UEB`
	`MARC`	`MARC_UEB`
	`MARM`	`MARM`
	`MAW1`	`MAW1_UEB`
	`MEAN`	`MEAN`
	`MVKE`	`MVKE_UEB`
	`SY`	`SYST`
	`WLK2`	`WLK2_UEB`

Screen 2 — Inbound Data Source for the ARTICLE object. This list is the entire surface area GUARD can check against directly. Anything beyond it (database lookups, cross-BO joins, custom Z-tables) goes through OSQL or a Custom Data Source.

3 Screen CUSTOM DATA SOURCE

Project → Custom Data Source · maintained by functional

Build extra Data Sources by joining what's already in the rule.

Custom Data Sources are project-level WITH-clause queries — each row is an OSQL select that produces a virtual table the project's rules can then reference. The #TABLENAME placeholder in the SELECT picks up the corresponding Inbound Data Source table at runtime, so the query joins against whatever the BAdI fed in.

Placeholder syntax: @SY-MANDT for system fields, &EBELN for fields from the rule's data, #MARA for an entire table from the Data Source.

‹ SAP Display View "Custom Data Source": Overview

Object: ARTICLE ⊞

Project: ARTICLE MGMT

Custom Data Source

Table Name	No.	Table Name in DB	Description	Data	Data Preview
`A_MARA_DELETED`	0001	`MARA_UEB`	Data from MARA only if Article is Delete	⇲	WITH local_mara AS ( SELECT * FROM #MARA ), local_mvke AS ( SELECT *…
`A_MARC_DELETED`	0003	`MARC_UEB`	Data from MARC only if DC is Delete	⇲	WITH local_marc AS ( #MARC ) SELECT * FROM local_marc JOIN t001…
`A_MVKE_DELETED`	0002	`MVKE_UEB`	Data from MVKE only if S.Org is Delete	⇲	WITH local_mvke AS ( #MVKE ) SELECT * FROM local_mvke WHERE…

Screen 3 — three Custom Data Sources that surface only the article rows whose deletion conditions are met (per article, per DC, per sales-org). Rules then check against these synthetic tables instead of writing the same WITH-clause five times.

4 Screen CHECKS

Project → Functions · OSQL Query

Two of the three check kinds, side by side.

Functions point at an ABAP class implementing ZIF_GUARD_FUNCTION for richer logic. OSQL Query holds a free SELECT statement that uses @SY-…, &FIELD, and #TABLE placeholders to build a query against the database. Decision Tables (a third check kind, not pictured) work similarly but resolve through an RSDF parameter.

‹ SAP Display View "Functions": Overview

Object: ARTICLE

Project: ARTICLE MGMT

Functions

	Function	Class Processor	Description
	`MARC_ALL_FIELDS`	`ZCL_GUARD_MARC_ALL_FUNC`	GUARD Check for MARC all fields
	`MVKE_ALL_FIELD`	`ZCL_GUARD_MVKE_ALL_FUNC`	GUARD Check for MVKE all fields

‹ SAP Display View "OSQL Query": Overview

Object: ARTICLE

Project: ARTICLE MGMT

1. Usage of SY — Example (@SY-MANDT / @SY-UNAME / @SY-DATUM)

2. Usage of Table Fields — Example (&EBELN / &MATNR / &PARTNER)

3. Usage of Table From Data Source — Example (#MARA / #EKKO / #BUT000)

OSQL Query

	OSQL Query	Description	Table Name	Select Preview
— No queries defined yet —

Screen 4 — Functions and OSQL Query lists. The OSQL screen header reminds the user of the three placeholder kinds; the function records simply name an ABAP class that implements the GUARD function interface.

5 Screen RULES

Project → Rules · the catalogue of checks

Every rule in one list, with its activation flags.

Each row is one check. The four flags decide how the rule behaves at runtime: Active (does it fire?), Live (is it production-grade vs. still in test?), Func.Messg (does the function class supply its own messages, instead of the configured ones?), Statistic (write to ZGUARD_STATS on every execution?).

‹ SAP Display View "Rules": Overview

Object: ARTICLE

Project: ARTICLE MGMT

Rules

	Rule	Active	Live	Func.Messg	Statistic	Description
	`AM014_MARA_DISC`					MARA Article Discontinuation
	`AM015_MARC_DISC`					MARC Article Discontinuation
	`AM016_MVKE_DISC`					MVKE Article Discontinuation

Screen 5 — three rules in ARTICLE MGMT, all checking that an article truly is discontinued in MARA, MARC, and MVKE before any change is allowed against it.

6 Screen RULE: AM014_MARA_DISC

Project → Rules → AM014_MARA_DISC · Filters / Conditions / Messages

Inside one rule — the four lists that define it.

Filters narrow the rule to a specific scope (here: only two test users get this rule when configuring it). Conditions name the tables whose result decides whether a violation exists. Messages are the multilingual error texts that go back to the user, with &… placeholders that get substituted at runtime. (Check Steps look the same; omitted for brevity.)

‹ SAP Display View "Filters": Overview

Object:ARTICLE

Project:ARTICLE MGMT

Rule:AM014_MARA_DISC

Filters

	Table Name	Field Name	Description	Data	Data Preview
	`SY`	`UNAME`		⇲	999USER01;999USER02

‹ SAP Display View "Conditions": Overview

Object:ARTICLE

Project:ARTICLE MGMT

Rule:AM014_MARA_DISC

Conditions

	Table Name	Is Empty
	`A_MARA_DELETED`
	`SY`

‹ SAP Display View "Messages": Overview

Object:ARTICLE

Project:ARTICLE MGMT

Rule:AM014_MARA_DISC

Usage of reference to Fields from Table — Example (&EBELN / &MATNR / &PARTNER)

Messages

No.	L	MsgNo	Type	Msg.var. 1	Msg.var. 2	Msg.var. 3
0001	EN	999	E Error	Deletion conditions are fulfilled	for Article: `&MATNR`.	No changes are permitted.
0002	DE	999	E Error	Löschkonditionen auf Mandantenebene…	für Artikel: `&MATNR`.	Änderungen sind nicht zulässig.

Screen 6 — Filters / Conditions / Messages for rule AM014_MARA_DISC. The rule is currently scoped to two test users via SY-UNAME; once it goes Live the filter row is removed and the rule fires for everyone.

Same screens. Same logic. Hundreds of rules.

Every Object follows the same shape; every Project follows the same shape; every Rule has the same four parts. Once a team has walked through one rule, they can write the next ten without help.

See real situations → How to install