Process Object Layer

[Former Member]

Hi,

I just encountered a concept of POL(Process Object Layer).

It seems that POL has a particular layer in ABAP stack to help process management.

How does POL work?

I would like to know how PO is used in interface and BPM technically.

Also, my another question is about SOA approach in technical.

If there are unit function modules/web services that can present an enterprise service,

then should we expose single enterprise service putting together all the relevant unit services?

Or should we build process object or business processes to orchestrate single processes?

Looking forward to hear from you, expert.

[Former Member]

Process Object Layer:

The Process Object Layer has been introduced as an additional software layer in the architecture model:

Communication between the software layers and the Process Object Layer is based on Web services. Back-end applications are therefore integrated across all systems.

To communicate with back-end systems, the layer consumes the synchronous and asynchronous services provided by the back-end systems.

The layer can also consume services from non-SAP systems.

The layer provides new object-specific services (POT/PROT services) for the business processes to be implemented. These can in turn be consumed by front-end applications or tools for process orchestration (such as SAP Business Process Management).

This layer therefore acts as a mediator between back-end system and front-end channels. It enables transparent status and event management for all business objects that are involved in a business process.

Data required for the business process is persisted.

Business Process Management (BPM) Process: POT is integrated with BPM. The BPM orchestrates the POT services sequence.

Using BPM is optional for orchestrating a POT. We can also use other tools for handling errors.

Thanks & Best Regards,

Deependra

[Former Member]

Deepandra already explained it very well. I would just like to add some information.

I would like to emphasize that orchestration is not the major target of process objects although like in BPM and any other implementation it is necessary to call the services in a sequence.

Process Objects (POTs) provide a transactional behaviour

• based on the 'phases' initialize, check and maintain, execute
• including full service enablement, which allows to use it also in different environments (interaction with front ends, switching between input channels,...)
• with a work in progress persistency (incl. versions) combining views of backend objects with process specific data, accessible any time via services.
• with a comprehensive status model on overall level as well as per involved Business Object (unchecked, checked, erroneous, failed, to be compensated, in maintenance, cancelled, in execution, ...)
• offering optionally UIs to maintain and view the process object data including CHIPs for integration with UWL
• including locks, authorization, archiving
• including integration with Process Observer and BRFplus
• sending events in case of completion or failure via information service
• implementing most of the functionality via code generation in ABAP, based on the predefined model

Persistent Retrieval Objects (PROTs) are a spin-off which focus on data provisioning across multiple components:

• based on phases (pre-fetch, complete)
• includingfull service enablement to access the data (also incomplete) , refresh data, etc.
• with a persistency as buffer
• with a comprehensive status model (waiting, running, finished, expired, ...)
• sending events in case of completion as well as expiration via information service
• partial information available
• if possible parallelization of data collection
• implementing most of the functionality via code generation in ABAP, based on the predefined model

Best regards,

Werner