Standard EMP Implementation Locking
In the standard system, SAP delivers the EMP implementation Locking with which you can use an agent instance as a lock server for a resource in production.
The EMP implementation provides a queue for lock requests. Each entry in the queue is given a unique ID, for example, the SFC of the product that is to be produced by the resource. Only the first entry in the queue has access to the resource. The other lock requests are either rejected after a specified time or they move to the first position in the queue during this time and gain access to the resource. The implementation provides the following methods:
|
Method |
Input Parameter |
Output Parameter |
Function |
|---|---|---|---|
|
_Lock |
inHandle inTimeout |
outSuccess |
Locks the resource that is modeled by the agent instance. The input parameter inHandle needs to contain the unique ID of the lock request. This might be, for example, the SFC of the product that is to be produced by the resource. If the lock cannot be set within the timeframe set by inTimeout, outSuccess is “false”; otherwise it is “true”. If the lock was able to be set, other lock requests are rejected using the method _Lock provided the resource has not been unlocked again using _Unlock or_UnlockAll . |
|
_Unlock |
inHandle |
outSuccess |
Unlocks the resource that is modeled by the agent instance. The input parameter inHandle contains the unique ID of the lock request. If there is a lock of the resource for this ID, the lock is removed and the output parameter outSuccess is set to “true”. Otherwise it is “false” and any existing lock remains. If the lock for the ID was able to be removed, the next ID in the queue moves up and can use the resource. |
|
_UnlockAll |
outSuccess |
The _UnlockAll method removes all lock requests that have been sent to the resource. In this case, the output parameter outSuccess is “true”. For example, you use the method for initializing the production flow. |
|
|
_ListLocks |
outHandles |
Provides the list of IDs of the lock requests that have currently been sent to the resource and that have not yet been rejected. The first ID in this list is active and can use the resource. The subsequent IDs are in the queue and are rejected if they cannot go to the top of the queue before the timeout. |
Using a sequence of lock requests, the following graphic shows the behavior of the lock server in the EMP implementation locking:
None of the methods of the EMP implementation Locking need any additional destination system call.
Example
In production, you are using a robot that is used by various parts of the production plant and therefore gets work orders from various clients. Then you can use a PCo agent instance as a central lock server for this robot and make sure that each client needs to request the lock on the resource before it can send a work order to the robot.