Business components for SAP

A business component is a reusable action named in the language of the business process: Create Sales Order, Post Goods Receipt, Release Purchase Order, Create Billing Document. It takes business inputs, performs the action through whatever interface is appropriate, and returns business outputs such as the document number. Components are where SAP knowledge lives in a framework, and designing them well is the single biggest lever on maintenance cost.

Anatomy of a component

The ISTQB syllabus describes the design patterns behind this. The facade pattern hides implementation details and exposes only what testers need. The page object model keeps locators for a screen in one class, so a UI change is fixed in one place. The flow model adds a facade over page objects that holds the user actions, so steps can be reused across scripts. A business component is essentially a flow-level facade: it orchestrates page objects or API calls into one business action.

Granularity

Too coarse, and components cannot be combined: "Run Order to Cash" is a test, not a component. Too fine, and the test reads like a recording: "Click Create, Enter Sold-To, Press Enter". The right size is one business transaction that a process owner would recognize and that leaves the system in a consistent state.

Interface independence

A strong component hides how the action is performed. Contoso's Create Sales Order component has two implementations: through the Manage Sales Orders Fiori app, used when the test is about the user path, and through the released Sales Order API, used when an order is only setup data for a later step. The test chooses the mode by intent ("as user Maria" versus "as setup"); the component signature stays the same. When the Fiori app changes, only the UI implementation changes.

Return values and assertions

Components return business facts; tests assert on them. A component that both creates the order and asserts "net value equals 12,000.00 USD" mixes two responsibilities and cannot be reused for a test that expects a different value or an error. Let components fail only when the action itself could not be performed, for example the save did not happen, and return messages so the test can assert on expected warnings or errors.

• Name components with business verbs and objects, as the process owner would.
• Document inputs, outputs, preconditions and postconditions in the component itself.
• Return keys and business values; never hide document numbers.
• Do not assert business expectations inside components; leave that to tests.
• Version components with the tests in source control and review changes like code.