EHSM Foundation - PCBO and PCO mapping

[Former Member]

Hi Experts,

In process foundation configuration while defining the process we maintain the PCO class to the Process Variants, this is linked to the corresponding PCBO, for Example: PCO Class CL_EHHSS_PCO_INC_ACTION_PM the corresponding PCBO reference is EHHSS_PROC_CTRL_INC_ACTION, you can see this in process definition check reports.

Where is this reference between the PCO Class and correcponding PCBO maintained?

[Joachim · Accepted solution]

Hello Praveen,

The link between PCBO and PCO is established implicitly. You could check also the package structure of EHSM. The PCO (which is a class) and the PCBO wich is a BOPF object are usually stored within the same package. For you example it is: EHHSS_PCBO_INC_ACTION_IMPL ("Implementation of Process Control for Incident Action").

The direction of the relation is only from PCBO to PCO not vice versa, because it relies on configuration. If you look at the PCO runtime objects, they do always carry a reference to the PCBO in their attributs.

The documentation about this can be found here: https://help.sap.com/saphelp_ehsext60/helpdata/en/b4/07cb5f7c7c402a93744fda1bbad88d/content.htm

To better understand the concept I will outline it quickly:

You have let's say an incident you created (BOPF: EHHSS_INCIDENT). Usually during the save process a workflow is created. This done the following way:

Within an action of the Incident BOPF the PCBO, another BOPF object, is created. This PCBO is created by a BAdI: badi_ehfnd_wff_pcbo_creation
The action of the original BOPF object (e.g Incident) knows what it is doing and therefore carries EHSM component, purpose and variant for the PCBO. If you did not implement a new implementation of the BAdI, class CL_EHFND_WFF_DEF_PCBO_CREATION is where the PCO class is determined and the PCBO is instantiated as well as the workflow is being started.

I hope this helps to better understand what EHSM is doing here.

Regards

Joachim

[Former Member · Accepted solution]

Hi Joachim,

Thanks for your detailed explanation.

Let me know whether my inference is correct, in case of a new variant requirement:

1. Define the new PCO Class in the Process Definition step for the (component, purpose & Variant)

2. Implement BADI_EHFND_WFF_PCBO_CREATION to determine right variant so that the system finds the right PCO Class from the above step 1.

3. The kind of PCBO created is predefined in the system based on the (Component, Purpose) and this PCBO that is created cannot be changed to a different PCBO name by the BAdi.

Thanks 

[Joachim · Accepted solution]

Hello Praveen,

it is even a little bit easier 😉

1. Yes, you need to create a PCO class for the workflow handling.

2. You maintain the process in customizing with component, purpose & variant:

Here you will also assign the PCO class.
There is acutally no need to define a new implementation of the BAdI.

If you have a look at the picture in the SAP help manual, it shows that the PCBO is invoked by the user interface. As stated in my previous post this may be done e.g. after a certain button has been pressed.

For Actions triggered by an incident all this is done in class CL_EHHSS_INC_TASK_FDR (the feeder class of the UI). Method IF_FPM_GUIBB_LIST~PROCESS_EVENT triggers the creation of the notification in PM and starts the actual workflow by invoking the PCBO in method START_ACT_WORKFLOW.

Concerning yourd third question: The PCO is based on component, purpose and variant. The PCBO (which is actually the BOPF object wheras the PCO is the "workflow manager") is defined within the UI. You cannot easily exchange a PCBO, but you can enhance it. By enhancing it you can introduce additional logic and partially also change the logic.

Regards

Joachim

[Former Member · Accepted solution]

Thanks Joachim, for your helpful answer.