|
| Re: what is the best way to log all form fields from an external mashup? [message #1486925 is a reply to message #1486300] |
Tue, 25 November 2014 11:56   |
|
Dan,
so the regular audit trail does not satisfy your requirement because the data may be overwritten in later steps and you need versioning?
If instruction fields are not accessed after the activity instance anymore then you don't need versioning for those and can simply use out data mappings to store them in the audit trail. If you need to keep a copy of the same process data's values over several executions of activity instances that possibly modify them, then you can use sub processes with scope sync separate. That way each sub process gest its own data scope. The separate scope of the sub processes will not be accessed anymore once the subprocess is completed. That approach would work purely with modelling.
If you want to avoid any impact on the model and adding code is acceptable then you can leverage the SPI IActivityInstanceMonitor
You could also come up with an approach that leverages the versioning mechanism of the document management system or combine it with this SPI.
Does that help?
Best regards
Rob
|
|
|
|
| Re: what is the best way to log all form fields from an external mashup? [message #1487967 is a reply to message #1487923] |
Wed, 26 November 2014 07:52 |
|
Dan,
agree, if you need this for every manual activity then the sub process approach is not the solutions.
a) Usually I would simply call a REST service from a custom HTML5 UI to write away the data. However, if you want to keep using manual activities with generated UIs then that is not an option. (The subject says external Ui mashup. If those pages are under your control then this option is valid).
b) Binding between an activity and a data is usually done via data mappings. You could implement a data type which stores data externally (like the Hibernate or EJB data types) but supports versioning. (If I remember it correctly a project implemented this for SDOs, but I don't have access to the code). The source of the Hibernate or Documente data type could serve you as a starting point and give you the structure / interface Stardust requires. The implementation of the load and save methods would have to be exchanged with the desired logic.
This approach would allow you to keep using manual activities and write the data via the out data mapping. The model would look nice and you would not require an extra service call.
c) It is very easy to hook into the SPI I mentioned. It gives you access to the complete activity instance. In your custom implementation you could distinguish between activities for which you want to version the data and others, then call the service that versions the data.
I any case the persistence could be the DMS (or not). The benefit I see is the ootb versioning. You certainly know that a "document" can be any kind of file including e.g. JSON or XML files.
IMO b) would be the nicest solution while c) would likely be the fastest. If we came to a nice result then it would also be worth adding it to Stardust so the maintenance is ensured.
Best regards
Rob
[Updated on: Wed, 26 November 2014 08:02] Report message to a moderator |
|
|
|
|
Powered by
FUDForum. Page generated in 0.01578 seconds
] 
Search
Help
Register
Login
Home
