File uploads, attachmens, forms, and custom FormTypes

[rkroll]

We have a business requirement to add multiple file upload fields within a form/process.  In this specific use case, we need to upload a large number of photos as part of our process, and are unsure how to implement this within Activiti.  If I was to create a new custom form type (FileFormType), is the type of data that would be in the object parameter the binary data of the form post?  Once this data is posted, we would want to store it externally to the engine (most likely in S3), my current thought is that this could be handled via a ServiceTask.  Is this the best method to handle this type of use case with an Activiti rendered form?

Another thought I had was to use an external REST endpoint to submit the file uploads, supplying a correlation ID, and to use the TaskService.addAttachment API to associate the uploads to the task.  My thought was that this would keep the potentially large binary data outside of the Activiti engine, while keeping the properties of the data available to the process.  Is this in line with the intentions of the newly added addAttachment API?

Any direction anyone can provide on how to address this type of use case would be greatly appreciated.

Thanks,
Rich

[ronald_van_kuij]

Is this the best method to handle this type of use case with an Activiti rendered form?

Personally, I'd create my own webapp for these kinds of applications.

My thought was that this would keep the potentially large binary data outside of the Activiti engine, while keeping the properties of the data available to the process.

Good idea.

Is this in line with the intentions of the newly added addAttachment API?

Haven't used it, so no idea (yet)

Any direction anyone can provide on how to address this type of use case would be greatly appreciated

I think you are on the right track.

[rkroll]

Ronald,
Thanks for the feedback!

Is this the best method to handle this type of use case with an Activiti rendered form?

Personally, I'd create my own webapp for these kinds of applications.

In our use case, this is a single step in a much larger work-flow and would be extremely painful to externalize into a separate web app.  IMO this is the main reason to use a work-flow engine in the first place - my question is targeting how people are handling file uploads as part of a process.

Is this in line with the intentions of the newly added addAttachment API?

Haven't used it, so no idea (yet)

Would love to hear your experiences when you dive in!

Rich

[ronald_van_kuij]

Is this the best method to handle this type of use case with an Activiti rendered form?

Personally, I'd create my own webapp for these kinds of applications.

In our use case, this is a single step in a much larger work-flow and would be extremely painful to externalize into a separate web app.  IMO this is the main reason to use a work-flow engine in the first place - my question is targeting how people are handling file uploads as part of a process.

Extremely painful? Hmm… My experience is the other way around. It was very painful to get the ui *form* technologies of Staffware (sorry, my former employer decided to 'give' them €100.000,- and eventually do nothing with it ,but I had to learn some things from it), jBPM and now Activiti to do what is needed in a form. Things like dropdowns populated from other datasources cross validations, visibility of fields (conditionally) etc… never was easy, nor was extending them. We never used the form properties of these engines, nor will we ever do that. It's (imo) great for quick demos and limted poc's but for full production environments, custom forms (jsf or xforms) were way easier to use, extend etc. It's not that e.g. vaadin is wrong, not at all, but is the abstraction layer in between that is almost always the limitattion. Using the api of activiti for the workflow but storing domain data somewhere else (not only the attachments) was easier. We only stored data in the engine that was in one way or another relevant for making decisions and still had a lot to gain by using a workflow engine… just not the form technology

But… your milage may vary…

[rkroll]

Ronald,
We are new to the implementation details of a workflow engine, so thanks for your feedback, its invaluable!  What I hear you saying is that you have an Activiti user task route to an external form rendering engine (using your framework of choice), which renders the form and upon form submission will perform all the complex business rule checks/validation.  If all this is successful, your web app will then submit a subset of the data into the workflow engine (I suppose via FormService.submitTaskFormData(String taskId, Map<String, String> properties) ?), which triggers the engine to move the process forward.  Does that summarize the pattern you are describing?  How are you handling correlation of form to task?  Are you keeping track of the engines taskId and passing it through your web app?

We only stored data in the engine that was in one way or another relevant for making decisions and still had a lot to gain by using a workflow engine… just not the form technology

This is the pattern I am looking to follow - only inject into the engine the things which need to be there for process decision making.  The flip side of the coin is that if we could add server side validation as well as configuration time determination of which data was passed to a ServiceTask and then discarded vs. data which needed to be persisted as process data, we could eliminate a series of components/code which only exists to support form rendering.

[ronald_van_kuij]

Rob,

First of all, keep in mind that this is one opinion and therefor not the right/only one. It's just my experience from the past couple of years with jBPM and now Activiti and the requirement of fairly complex forms. Currently real orders, invoices, despatch advices, but in the past with a former employer insurance claims, car damage reports etc not some simple vacation request 🙂

Your summary is spot on. 'The tracking' is done by using the formkey from the processdefinition. This we do use as a reference to the form. We use the tasklist to get a taskid and from that use the taskservice to get the formkey and present the user with the correct form.  These forms are self-contained so all info on what should go back to the processengine is defined in that form. In our case xforms which contain several xpath statements that retrieve values from the result of the submission (on the xforms level) and extract those fields that are referenced via the xpath and submit those to the engine.

Regarding the amount of data, we (need to) store the full xml which is the result of the form. These need to be shown again in a kind of 'what did I send/enter at that time). In addation the order xml needs to be used to generate an invoice. These are 'mapping' services in the processflow wich just retrieve the correct xml by getting the referenced 'messageid' from the process instance.

Again, this is one way, not the way, take from it what you like, but do not hasistate to do things differently if that suits you better.