My own enum type

[bartek_andrzejc]

Hey guys,

I've recently encountered a problem with my custom enum type. I need to have a form type which has onChange event attached to it in our inbox and so I've created custom form type.
I've tried to extend EnumFormType, but apparently it's not so easy. Such a type couldn't process options provided in .bpmn file builded in Activiti Designer.
I've tried also to build my own type from scratch using constructor with one Map<String, String> argument but it didn't work either.
Could you tell me is there a way to get to bpmn activiti:value elements from a custom type?

Thanks in advance.

[bartek_andrzejc]

I've just looked at Activiti code and that's how I see it - To get to the activiti:value elements they need to be passed to my FormType in FormTypes class. FormTypes class is used in DefaultFormHandler in such a manner:
[java]
FormTypes formTypes = Context
      .getProcessEngineConfiguration()
      .getFormTypes();
[/java]
Now the question is: Can I add my own class extending FormTypes and use it somehow in engine configuration?

[ekolesnikov]

We looked into it here and it seems that "enum" fields receive special treatment not available to extension fields. One of the options would be extending FormTypes class and wiring it up manually or via Spring configuration (just call setFormTypes() before callini init() on ProcessEngineConfiguration.

However, we found out that using activiti Form extension is quite limited and not really usable in production, so we moved to using FormKey property and supplying our of form definitions in .json files in deployment bundles - this gave us all the flexibility we need, but we did have to re-implement /form/form-data web service to do type mapping and validation.

The other issue you may come across is that Activiti Web Modeler is built on quite ancient ExtJS 2.0.2 (unsupported since circa 2009) and Signavio Core Components (deprecated in 2011) libraries and is extremely un-friendly to extensions, especially in forms department, so you'll probably end up editing raw BPMN XML files manually anyway.

Our approach to forms management in Activiti:
- Form definitions are stored in .json files and bundled in .zip deployments along with .bpmn.xml files and referenced using FormKey property on User Task (i.e. "my-process.zip/forms/my-form.json" is referenced as "my-form" FormKey);
- Each field has to have multiple properties: Label, Description (either static text between Label and Input or Help icon content - up to the UI), Input, Placeholder, Hint (small grey text under the Input), Data Type, Required/Editable/Readable properties, Validator class;
- Original /form/form-data web service is disabled;
- GET /xform/form-data web services pulls appropriate .json file from the deployment based on the FormKey property and sends it over to the client;
- POST /xform/form-data web service matches posted data with the form definition, applies field conversion and validation and does whatever the original /form-data did;

This allows us to control full form lifecycle, use external form builders (similar to this one - http://minikomi.github.io/Bootstrap-Form-Builder, we actually forked and extended it) that are user-friendly enough even to non-techie types (BAs etc) and allow us to do whatever we want with it. One of the advanced examples we have is "dynamic" form similar to shopping cart that is getting serialised in Activiti process variables.

[bartek_andrzejc]

Thank you ekolesnikov for such a complete answer. I've noticed, that enum and data form types are recieving special treatment so it takes rather deep interference with Activiti Engine to add new enum-like type.

Your approach is very interesting and I would like to use somethink alike in our project but I've got some concerns:

-Does the Activiti Explorer allow us to deploy zip files with .bpmn file in root directory and some additional files in subfolders? I know that .bar files work, but I've never tested zip.

- We need to persist form data after process is finished. With default "audit" storing setting we have it covered but if we would use custom forms and put form data to execution variables we would loose it. When you use your json form by formKey, do you also specify normal bpmn form inside userTask to let Activiti know what variables to persist? How does distinguishing form variables from execution variables work? Can we set some variables to execution as persisted form fields? How does this form persisting functionality even work? I guess that at the end of process Activiti goes through all the forms and saves all "value" fields from FormTypes, but I'm not sure. In such case can we just create suitable FormTypes list for UserTaskForm when getting a task by rest and then saving values when posting task data?

I hope my questions are at least understandable. Thank you for your time.

[ekolesnikov]

Hi Bartosz

Sorry for taking so long to answer - I forgot to subscribe to the thread.

Answering your questions:

1. I did not see any problems with zip files upload - actually, I never bothered renaming them to .bar and it worked perfectly well.

2. Not sure what "audit" storing is - if you refer to ACT_HI_DETAIL table then you have a couple of options there.
First, and this was our initial approach (still used though) was to re-implement SubmitStartFormCmd.execute() in our bespoke RESTful web service to provide validation and data mapping facilities aware of our JSON-serialized forms.

Second, and this is how we're doing it now, is to override  ProcessEngineConfiguration's getDefaultBpmnParseHandlers() method and supply our own extension of StartEventParseHandler that would use our custom StartFormHandler instead of hard-coded DefaultStartFormHandler. At this point we're pretty much free to do whatever we want to do - namely, supply our own FormPropertyHandlers based on JSON-serialized form definition. This allowed us to comply with DRY (or DRActivitiDevelopers for that matter) principle and go back to using vanilla /form/form-data web service.

Hope that helps.