Skip to Content
Technical Articles

Workflow for Deactivation/Deletion of Technical Objects(Equipments/Functional Locations)

Objective:

Delete Equipment/Functional Location related technical objects at the time of Deactivation/Deletion. The related technical objects can be Maintenance plans/items, orders, notifications etc.

 

Configuration:

SAP has provided a standard solution for this which you can activate by navigating to the below configuration.

SAP Customizing Implementation Guide > Plant Maintenance and Customer Service > Master Data in Plant Maintenance and Customer Service > Technical Objects > General Data > Set Workflow for Deactivation/Deletion of Technical Objects

 

 

Activate the required process types for your event. For example, if you want to use EQUI(Equipment) DELETED(when Equipment deleted) event select the Active checkbox for that event.

Below example Activates 3 process types – Maintenance Plan Items, Orders, Notifications

 

A short description of what the Process Type means can be found below:

 

From the above table, select the Process Type that is activated and select Assign Activities to Process Type:

 

To understand what each Activity means, select the Object Types and then select the Target Obj.(in this case EAM_MTI for Maintenance Plan Item):

 

Now select Details for Activities(Bg. Obj Type, Bg- obj ID, Dialog Task are all pre-configured):

Here, Bg. Obj Typ and Bg- Obj.ID determine what workflow or a standard task will be executed.

 

 

Post Configuration changes:

The activated process types are called through a workflow which are triggered by the Business Object events. (e.g. EQUI DELETED)

 

Activate the required Triggering Events in the below Workflow Templates(Transaction: PFTC):

  1. Workflow Pattern: 800023
  2. Workflow Pattern: 800044
  3. Workflow Pattern: 800058

Triggering Events and Event trace:

Now, for this example delete an equipment and check if the Workflow events are triggered and have a receiver attached to them:

SWEL – Triggered events

Contains a receiver which triggers the Workflow:

Now once the workflow is triggered, it will trigger the other Workflows to call the implementation class for different Object Types that we saw during our configuration. As we had activated Process Types for Maintenance Plan Items, Orders and Notifications, it triggers the below 3 events:

 

This will then call the Activities associated with the Process Types and generate Work Items which can be seen in SWIA:

 

Classes/Code associated with Standard Activities:

The Activities that we saw have associated classes with them. An example of this one is shown below:

Example of INCI activity of the Maintenance Plan Item Object –

Class: CL_EAM_WF_ACTIVITY_INCI

 

The above class has methods EXECUTE_MY_ACTIV_IN_BACKGROUND and EXECUTE_MY_ACTIVE_WITH_DIALOG where the code would reside. In the configuration if the Checkbox for Only Dialog is ticked it will call EXECUTE_MY_ACTIV_WITH_DIALOG, otherwise it will call EXECUTE_MY_ACTIV_IN_BACKGROUND.

 

Now, the question is how it determines which class is for which Activity and how can we customize it. This framework uses inheritance to determine which class needs to be called for the Activity.

All the Activity classes need to have the class CL_EAM_WF_ACTIVITY_ABS_BASE as a Super Class. The framework fetches all the classes which has this as Super Class and selects the Top Most  sub class. The framework then calls the method GET_ACTIVITY_TYPE of each

Below is the GET_ACTIVITY_TYPE method for the class CL_EAM_WF_ACTIVITY_INCI:

 

On the same lines, you can add your custom Activities and create custom class and inherit CL_EAM_WF_ACTIVITY_ABS_BASE to write your own code to change the Technical Objects. Just make sure the GET_ACTIVITY_TYPE method returns the name of the Activity that was assigned in the configuration.

 

Regards

Chandan

2 Comments
You must be Logged on to comment or reply to a post.