Hi RasaiyaNadar, Can you add few more details on why the use case araised?
if can't share because of any business reasons... Here is what you can try: As @Santanu suggested, you can write a declare trigger on commit and save option selected on Declare Trigger rule and call an activity which you want. If you are expecting the activity shouldn't run in current transaction, can you try checking "Trigger activity as "In Background on copy" . Pleae refer to Declare Trigger rule form about this setting. I've not tried this option, but you can certainly try.
i think there is also concept callled nested transaction, but this will not work in your usecase.
Tried the background copy option,did nit work though.
you can easily recreate this create a declare trigger for commited save ,in that trigger call an activity that does an rdb list which fectches the increment status of the current object and writes it in a file. My requirement is similar on commit of an work object I need to generate a report.
I have to agree with the person asking for the business case. Why are you trying to do this? In what way are the OOTB facilities in the system failing to meet your business needs? My guess is there is a better way to meet those needs than the approach you are taking, but without a clear understanding of what and why, I can't really offer any meaningful guidance.
I am guessing that this "report" generation must be required to send some data about that specific work object. I agree with the option suggested by eric_osman. Post the submit of your business operation, we can have a Wait shape which will perform a commit in Pega. The Wait shape can have a wait time of 1 sec post which the process can move forward and call your report generation activity through a utility. This should give you a near real time processing. In 6.x world, probably the same feature will be implemented via an Assignment shape with an SLA.
How about having a flow step just after the one in which the work object has been written. That step will be confident that the data was already written, and can do whatever you were planning to do in the trigger. /Eric
Considering the contraints that you have mentioned, have you also thought about queuing your work item to a an Agent. Commit operation for workitem and "queue to agent" will be part of single transaction. Report generation will be new transaction handled by Agent. Agent activity can be easily modified to cater to future changes.
Do we need to use the step method Queue to achieve this ? Will that get executed as soon as this transaction of commit ends ? Can you please guide me here as i have never used Queue.
We thought of writing the workobject id in a table on commit , and then an agent[runs in specific interval of time] would pick it up from the table and generate the report, but we rejected that thought because the requirement was for real time report generation
Any approach would be ok to me, just few constraints
1. It should be real time report generation, i.e as soon as the commit operation finishes the report should be generated.
2. It shoould dynamic ,i.e commit from anywhere and the report should be generated