S SHIELD
Stop bad data before it reaches the database

Stop bad data —
before it reaches
the database.

SHIELD is a configurable SAP validation framework that evaluates business rules at the moment of Save. It stops invalid data before it reaches the database and turns scattered hard-coded checks into transparent, transportable configuration.

See how it helps → How it works
The problem

Bad data sneaks in long before anyone notices.

In every long-running SAP project, business rules end up scattered across user-exits, BADIs, and includes — each one a separate piece of code, hard to find, hard to change, impossible to govern.

Every new check becomes a development ticket, even when the logic is just a value list or a "must not be empty". And the data-quality reports that do exist run hours later — by which time the bad record has already been used by downstream postings, IDocs, and replications.

The idea

Move the rules out of code, into configuration.

SHIELD turns business checks into customizing. A rule is a transparent pipeline — Filter ⟶ Steps ⟶ Conditions ⟶ Messages — stored in standard tables and transported between systems exactly like any other SAP customizing.

The framework plugs in once per Business Object — through a BADI, a USER-EXIT, a CUSTOMER-EXIT, or any place before SAVE where the relevant tables are available. From that moment on, anyone with SAP technical literacy can add, change, or retire a check without touching ABAP — and everyone in the project gets a single place to look.

How it works

Three layers — wire it up once, configure forever.

A developer enables SHIELD on a Business Object. From there, every new rule is configuration only.

1

Object

A developer wires SHIELD into the Business Object once and lists the tables that feed the check.

  • Contract, PIR, Article, Promotion, BP — or your own
  • One insertion point before SAVE
  • Declare the tables available to rules
  • Six lines of ABAP, usually under a day
2

Project

Each product or team gets its own Project — a cluster of rules for one purpose, e.g. CONTRACT_MANAGEMENT.

  • Group rules by product, team, or purpose
  • Multiple projects coexist on one Object
  • Transport-relevant or editable-in-PRD
  • One-click export/import of a whole Project
3

Rule

Every rule is a sorted, transparent pipeline — visible in one screen, transportable like any customizing.

  • Filter — when the rule applies
  • Steps — Decision Table, Function, or OSQL
  • Conditions — what must be true
  • Messages — what the user sees on fail
Why teams adopt it

Fewer mistakes. Faster new rules. A clean audit trail.

Real-time protection

Checks run before SAVE — not in a report hours later. Bad data never makes it into the database.

No code per rule

The framework is wired up once per Business Object. From there, every new check is configuration — no developer required.

Three flavors of check

Decision Tables for value lists, Functions for richer logic, OSQL for cross-table look-ups — pick what fits the rule.

Two transport modes

Flow rules through DEV → TST → PRD on standard transports — or set systems editable and maintain rules directly in production, with one-click Project export/import. No transport when a rule must change in PRD now.

Built-in trace

Every step of every rule writes a SLG1-style log on demand — perfect for debugging or for proving "the rule did fire" to an auditor.

Authorable by anyone

Functional consultants, developers, and SAP-fluent business users can all maintain rules. One source of truth, many capable hands.

Who it's for

Anyone who has to keep an SAP system clean.

SHIELD fits wherever a Business Object is created or changed — and someone, somewhere, has to make sure the data is right.

Master data teams

Consistent at the moment of save.

Articles, BPs, prices, contracts — kept clean before the record ever lands, not repaired in a report later.

Pricing & conditions

Enforce terms without scattered code.

Payment terms, currency, and scale rules become configuration everyone can see — not a user-exit only one dev remembers.

Data quality & audit

Prevent it at the source.

Move from "find it in a report" to "stop it at Save". Every rule is documented, transported, and traced for auditors.

Consultants & developers

Onboard a check without a ticket.

Functional teams add rules without ABAP; developers wire SHIELD up once and stop maintaining twenty user-exits.

Go deeper

See it in real situations.

Use cases

Five everyday SAP changes — article extensions, payment terms, promotions, business partners, master data — and the exact SHIELD message the user gets when something is off.

See the use cases →

Installation

Five steps for a developer to enable SHIELD on a new Business Object — insertion point, tables, six lines of ABAP, configure the Object, hand it to functional. Usually under a day.

See the installation →

Inside the app

A tour of the configuration screens — the navigation tree, Objects, Projects, Custom Data Sources, Decision Tables, OSQL queries, and the four parts of a complete Rule.

Inside the app →

See real situations where SHIELD steps in.

Walk through everyday SAP changes — extending an article to a new store, locking down payment terms, keeping promotions inside their contract window — and see exactly the message SHIELD shows the user when something is off.

Read the use cases →