I have a business requirement that looks tough to implement, especially given what I've seen so far in the forum. Specifically, the problem is that the originator of a workflow (process) needs to be able to alter data stored in the data fields of the process instance after the workflow has been assigned to (and possibly opened by) a user.
There are obviously multuple problems here. First is that K2Rom does not provide a way for the originator to even SEE the process once its been assigned to someone else. (I should at this point mention that our system is a WinForm client system ... we're not using any of the K2.Net UI, including reports, SmartForms, etc.) In other posts it is recommended that a custom report be created and used for this requirement, so for our needs I will create a view over the log database.
But what about when the originator needs to change data? First, I have to use information from my log records to identify the process instance and second I have to find an API in K2ROM to do this. Is it possible? I suspect it is not, because K2.Net does not allow the originator any access past creation. Can anyone confirm or deny, and better yet suggest a method to implement this?
Thanks,
-Kevin
Page 1 / 1
We built our own recall mechanism for the original to recall the item back so it'd appear in his worklist to change the data.
If the originator needs to make changes to the data then the process definition needs to be designed in such a way that the originator has a defined task item for making the changes. If there were an api that allowed the originator to make changes at any point what would stop them from, for example modifying their expense claim amount after the approval but before the check is cut.
If you want to give the originator the ability to modify the data at any point you could use a parallel activity (Originator Review) that is started at the begining of the process. The Originator Review activity would have a client event that allows for manipulation of the data and then upon completion the subsequent line would loop back to the Originator Review activity so that further updates could be made. At the end of the process the activity would need be expired by using a server event with a goto call (the goto call expires all open items and then goes to a finish activity)
-Eric
If you want to give the originator the ability to modify the data at any point you could use a parallel activity (Originator Review) that is started at the begining of the process. The Originator Review activity would have a client event that allows for manipulation of the data and then upon completion the subsequent line would loop back to the Originator Review activity so that further updates could be made. At the end of the process the activity would need be expired by using a server event with a goto call (the goto call expires all open items and then goes to a finish activity)
-Eric
Reply
View our Community Site Map
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.