SAP Process Orchestration was introduced 2012. SAP Process Orchestration is a package solution that combines the power of SAP Business Process Management (BPM), SAP Business Rules Management (BRM), and SAP Process Integration (PI) into a single, integrated solutions.
Features of SAP Process Orchestration are:
- It is based on single stack Java.
- Is a Business Process Modeling Notation (BPMN) standard.
- Is a graphic configuration that uses integration flows (iFlows).
The solution consists of the following components:
Business Process Management (BPM) allows you to design, execute and monitor business processes. BPM is part of the SAP Composition Environment (CE).
Business Rules Management (BRM) allows you to design, execute and monitor business processes. BRM enables organizations to automate decisions by using business rules.
AEX provides the connectivity capabilities of the Advanced Adapter Engine (AAE) as well as design and configuration tools (Enterprise Service Repository and the Integration Directory) to set up integration scenarios.
Introducing Business Process Management
Business processes are part of our daily life. Whether you order a coffee to go in your preferred coffee store or check in at the airport for your next business trip. During these activities you are part of a business process, triggering different events and providing input for specific steps.
A business process always has a start event (for example, ordering a cup of coffee the coffee shop) and a goal (receiving a cup of coffee). The process is a collection of related, structured activities or tasks, that produces a service or product for a certain customer. A Business Process can be divided into subprocesses.
Embedding an UI (SAPUI5, WebDynpro, etc.) allows you maintain data in the Business Process.
Rules enables organizations to automate decisions by using business rules.
Finally a business process consists of events (start / end events), decisions (gateways) and activities or tasks.
BPMN Processes
Pools and Lanes
Business Processes are created in pools. There is always at least one default pool. The default pool is automatically created when you model a process in the Process Composer.
The figure illustrates an example of a pool, containing 2 lanes.
Pool Characteristics are:
- A pool contains a single Business Process Modeling Notation (BPMN) process.
- A sequence flow is constrained in exactly one pool.
- A process diagram may contain several pools.
- A pool can be either active or inactive.
- A pool generally represents a logical collection of roles, organizational units, and systems.
Lane Characteristics
A pool is divided into lanes and is automatically created when you create a new process. A lane is a partition within a pool and is used for structuring and organizing activities. Lanes define the process roles that responsible for completing the activities in a process. Each process role is assigned to a particular lane and can represent internal roles, such as an account manager, or systems, like an enterprise application or an internal department.
Categories of Elements
The figure illustrates the four core elements, and how they are visualized in the process modeler.
BPMN defines the following categories for core elements:
- Flow objects — Defines the graphical behavior of a business process and contains the activity, gateway, and event elements.
- Connection objects — Links flow objects to each other and contains the sequence flow, message flow, and association elements.
- Swimlanes — Groups flow and connection objects by accountability within a business process and contains the pool and lane elements.
- Artifacts — Provides additional information about a business process and contains the data object, group, and annotation elements.
Basic Elements
The following three basic notation elements are used in a business process model:
- Activity — A step in a business process that requires a system or person to perform a specific action.
- Gateway — A gateway controls branching, merging, and parallel actions in a business process. A gateway does not represent an action.
- Event — An event shows a start, pause, resume, or interruption within an activity or the business process itself.
Procedure Models
A three stage procedure is used to form the basis for process development.
The three parts of this model are as follows:
- Strategic Process Model
- Operational Process Model
- Technical Process Model
The main objective of this three-stage model is to integrate IT departments with the rest of the business. This goal is best achieved when clear responsibilities within the process are defined and all stake-holders are involved and speak a "common language."
The Strategic Process Model
The primary target group of the strategic process model are process owners and process managers. In the early phases of process development, process participants and process analysts are also involved in the strategic process model. The strategic process model is intended to provide a basic, results-oriented representation of the process. The main goal of a strategic process model is to provide the fastest possible understanding of the process sequences while requiring no special knowledge of BPMN.
The strategic process model is developed from a high-level perspective without possible variations or errors. This error-free view of the process is also known as the "happy path."
The Operational Process Model
An operational process model is used to orient process participants to their daily work tasks. At this stage, a process analyst also analyzes the weaknesses of the process and begins designing improvements. The process analyst then uses the operational process model to develop a technical process model, which is given to the process engineer for further refinement and subsequent implementation in the real world.
The Technical Process Model
The objective of the technical process model is to refine the technical aspects of the process developed in the operational process model, allowing the process to run in a process engine. This level of the BPMN process can only be mapped directly as of BPMN 2.0.
Introducing Business Rules Management
Business rules represents the constraints on behavior of the business and the policies and guidelines which drive business decisions. Business rules are owned by LoB and not by IT.
Business users participate in and control rule definition and change, while business process experts model, validate, deploy, update, and archive business rules through their lifecycle. This enables IT organizations to work with business users to manage the business rules that drive process flow and execution.
SAP Business Rules Management (SAP BRM) enables organizations to automate decisions by using business rules. Business users participate in and control rule definition, while business process experts model, validate, deploy, update, and archive business rules through their lifecycle. As such, IT organizations can work with business users to manage business rules that drive process flow and execution.
Business rules describe the operation, definition, and constraints on the behavior of a business and enables decision automation. Business rules represent the core business logic of each organization and guide and control the basic business processes that form the back bone of any business transaction.
Business Rules examples:
- Corporate charters
- Management practices
- Regulatory forces
- Human resources management
- Marketing strategies
- Pricing policies
- Products and service offerings
- Customer relationship practices
The figure shows the three components of BRM:
- Rules Composer
- Rules Manager
- Rules Engine
Rules Composer
The Rules Composer is integrated into SAP NetWeaver Developer Studio as a separate perspective. It is a user-friendly interface that enables you to create rich rule formats It supports multiple data models for rules implementation and business vocabulary independent of the data model. Rules Composer provides validation of business rules, testing and refinement of rules based on test results and report generation for rule results. It contains extensive business rules modeling capabilities for business analyst and rules implementation functionality for business rules developers.
Rules Manager
The Rules Manager is a rule-centric application, based on SAP's Web Dynpro technology that provides a rule management environment. Rules versioning, repository service, permissions, access control and rules governance can be managed through the rules manager. Like Rules Composer, Rules Manager can validate, test, refine and generate reports for rules. It allows business managers, administrators, functional users to modify business rules and effect changes in real time.
Rules Engine
The Rules Engine is a high-performance, stateless EJB Engine. It includes Rete-based inference and sequential engines.
BRM Offerings
SAP Business Rules Management (BRM) contain rules modeling capabilities targeting business analysts and rules implementation capabilities targeting business rules developers.
Technical capabilities of SAP BRM for business rules composition and modeling use the following guidelines:
- Business analysts are enabled to model complex business rules in an appropriate format of their choice.
- Both business analysts and rules developers are capable of inspecting business rules consistency and resolving conflicts.
- Developers are able to use rule models with data definitions of their choice for implementing executable rules.
- A seamless navigation from business process to business rules through integrated modeling for processes and rules is used.
If-Then Rules use the following guidelines:
- Simple English like statements joined with and/or.
- Priorities for specifying sequences of execution.
- Rules overrides to declare mutually exclusive rules.
Decision tables use the following guidelines:
- Tabular representation of rules.
- Integration with Microsoft Excel.
- Features such as returning multiple rows of values and dynamic invocation.
Flow rules are laid out in a flow-like structure. Complex rules can be modeled using the following methods:
- Gateways to branch out into different paths.
- Rule scripts to hold a set of actions.
- If-Then rules.
- Decision tables.
- Other flows and rule sets.
A flow ruleset executes rules as designed in the Composite Explorer flow chart. Flow rulesets always have a single, main flow with potentially many other rule flows. The execution of the ruleset starts with the main flow.
A rule flow is a reusable entity within a flow ruleset and is based on activities associated with artifacts including rule scripts, rule flow, rulesets, rules, and decision tables.