Design Approach and Suggestions for Work Object Creation from Framework Layer to Implementation Layer
Our Design requirement is:-
From Framework Layer Level we will have to Create Work object down to the Implementation layer. i.e. the Someone who is logged in the FW layer will process some piece of information on an work object and then that information will have to be passed into various down the line Implementation layers and Work objects has to be spawned into the Implementation Layer as well.
We have come up with the below solutions:-
Agent Driven Approach :- The data will be extracted by the processor in the FW layer and will be kept in a Staging Table with Implementation specific information where the Work Object has to be spawned. Now Agents will be running in the individual Implementation layers. which will poll the staging table and once find a relevant entry will spawn the work item in the implementation Layer.
Now we all know Agents are not one of the most reliable source and because of multi noded environment there will be always issues with locking unless properly handled. We cannot use queue for agent here since we are sitting at the FW layer and cannot queue to an Implementation level Agent. So these will have be Advance Agent.
Service Driven Approach:- In this scenario we will have to create a Service SOAP in the FW layer which then will be consumed by the IMPL layers for creation of the work items. This again will have to use Agents because the service will have to be polled frequently to see if there are any new entries in the Staging table or not.
This again is not a very ideal scenario because every oncoming implementation will have the overhead of consuming the service. But one benefit is definitely because this is a service hence it can be consumed anywhere.
Direct Work Object Creation:- In this approach the work items will be created directly from FW to Implementation. where same set of starting flows will be used and the appropriate class will be passed as a parameter to the work object creation activity. It is working as we have done a small POC.
This approach is highly against the proper coding practice as we should never entertain the work object creation from FW to Implementation or in other words the initiation of the WO shouldn't be top to bottom directly. Also doing this means we are restricting the flexibility as we are dictating that only work object can be created with that data rather the decision should be left to Implementation what exactly they want to do with the Data.
Listener Driven Approach:- In this approach the data will be extracted as an XML file and the XMl file will be placed in different folders for the appropriate Implementation layer and Implementation will then listen to these Files and process the data / create the WO.
Overhead will be to maintain the Folders, Track the exceptions and creation of the listener activities in every implementation layer.
Which approach do you think make most of sense? any other solutions that you think is possible or you might have come similar requirement? All suggestions are welcome.
We are betting mostly on the Agent Driven approach
Apologies for the delay in you receiving a reply to your question here in the Product Support Community. We have been trying to find someone that could assist, but unfortunately we haven't been able to do so.
After some research we have decided it would be best for you to receive direct consulting help with your question. Please let me know if you prefer this option. If required, engage your account executive to arrange for Pega Consulting practice assistance.
When they have provided you with a reply, please share it here so that if any other Community member has the same question they will know the answer as well.
Its not that i haven't thought about that. but the only concern I had while designing it and using RedirectAndRun / ActionChangeClass is we are dictating from FW to Implementation and also down the line maintenance. In case if a new work object is not needed and a search and update feature is needed then we will run into trouble.
Finally decided to go via the Agent Route. Thanks for the comment.