Shaun, I am implementing a Mutex Behavioral Pattern to manage properly process concurrency and I am using the change requerst as a my synchronization object and I want to be able to remove the object when ever the mutex pattern is deleted and I do not leave clutter. For now I am marking the RC as closed but not really satisfaying the software pattern desing. I was expecting the consistency between the UI and the Nortbound API, because you canremove a CR on the UI.
Ok, yeah I see. Not everything you can do in the UI you can do in the NBWS. There are multiple targets that are not available and have not been exposed. Since this functionality is not exposed, I would suggest a CDETS to raise this enhancement request to the BU.
In the meantime could you create a new target type under Service type and just have a target object as your data object? I use this kind of idea a ton in my support automations. With target properties you can keep a ton of data in them and you can create/update/delete via CPO and it's included activities. I am not sure if you have to use the CR or you would be open to using a target data object.
Without getting into details of the implementation. My design is based on a traget type to implement the Mutex pattern. The CR is a used as synchronization and wait object. The RC is completely encapsulated by the methods that oprate on the target type. The only exposure of the RC is thru the operations Tasks view, which will still show the RC managed by the pattern because I cannot delete it. As a formal OO implementation no user should be aware of this and my pattern is not really acurate because I cannot delete the RC.
I will probaly enter a CDETS to request to implement in PO a concurrent process syncrhonization mechanisim, specially since PO allows parallelism and process concurrency.
I need to implement a MUTEX design pattern to avoid multiple concurrent processes from grabbing a shared object at the same time and make them wait until they are authorized to use the resource. The desing I am implemeting uses the CR notification mechanism to make the process wait until the specific "Authorized" state is set and the reason of the change has the Process Instance ID of the process that has gained (grabbed the MUTEX) turn to access the object.
I would of have use process events to implement this pattern but unfortunately PO does not provide an equivalent activity to "WaitForTaskStatus" to "Wait for Process Events".
In essense, I am implementing in PO a MUTEX just like those provided by the OS or .NET
I want to remove the CR since there is no value to have the DB record any longer after the MUTEX pattern instance is deleted or out of scope