in our client, we have a use case where we need the engine to control (based on modelation semantic) the properties that are supposed to be exposed/rendered in our custom UI(liferay portlet)…if we use the flowable already defined form types - string, long, enum,date and boolean - everything works fine, the problem is when we need to specify a new form type…we’ve been using the approach exposed by Jorran Barrez in his blog - http://www.jorambarrez.be/blog/2013/03/13/creating-a-new-form-property-in-activiti/ - but now, when converting from activiti to flowable, we can’t find a class in flowable, similar to AbstractFormPropertyRenderer (in fact, we’re not sure if we need this, once we render the types on our own UI)…we’re facing this error, while trying to start the engine:
org.flowable.engine.common.api.FlowableIllegalArgumentException: unknown type ‘multiselect’ actividadesOptions
at org.flowable.engine.impl.form.FormTypes.parseFormPropertyType(FormTypes.java:55)
at org.flowable.engine.impl.form.DefaultFormHandler.parseConfiguration(DefaultFormHandler.java:56)
Can anyone please help us clarifying how can we correct the bug that we’re facing or which could be a best (alternative) approach? in resume, our use case is; we need the engine to recognize custom/new form types, when fetching form properties, in a user task.
You can inject additional form types in the process engine configuration (customFormTypes or formTypes). Did you do this? The AbstractFormPropertyRenderer class is part of the Activiti Explorer and is used to render a form field type in the Vaadin UI. In Flowable 6 we switched to separate form definitions based on JSON with a new form builder for the Task form UI. But you can still use the basic form properties support when building your own form renderer in Flowable 6.
thank you very much for your quick reply.
What we’ve done was following the approach presented by Joran, so, maybe
the engine configuration isn’t fine with flowable (you may have evolve it).
In detail, we set the engine configuration (in application context), like
this:
<bean id=“processEngineConfiguration” class=“org.flowable.spring.SpringProcessEngineConfiguration”<property name=“dataSource” ref=“dataSourceBpm”
<property name=“transactionManager” ref=“transactionManager”
<property name=“databaseSchemaUpdate” value=“true”
<property name=“asyncExecutorActivate” value=“false”
<property name=“customFormTypes”
<list
<bean class=“blabla.bpm.process.formtypes.MultiSelectFormType”
</list
</property
</bean
(note: if i put the ‘close tag’ (>), this editor will not expose the string correctly)
Then we created the property class, extending AbstractFormType
(MultiSelectFormType extends AbstractFormType).
When we try to start the process (the form type is used at the beginning of
the process), we get a unknown type ‘multiselect’… exception, at
FormTypes.parseFormPropertyType
Should we inject/configure additional form types in other way?
Thank you very much for the explanation on AbstractFormPropertyRenderer,
we’re not needing it…we were using it because we thought the engine would
only recognize the field if it had this (rendering) configuration/injection.
so, I had a problem in the code while building the engine. Now, the engine already detects the form property but still have a problem: I can’t get the values of the property. Is there any particular approach so that the engine can recognize the values of my custom form property? This property is mostly like the enum form type,that’s working perfectly (also has multiple values). Below (in comments, the previous version), you can find the code that reflects the engine configuration and start.
Can anyone help me, please?
I found out the justification for the previous problem - class FormTypes only allows multiple values to enum property type (method parseFormPropertyType)…is there any reason for this? Is there any workaround for scenarios where there are multiple values assigned to a custom form property, that’s not an enum?
No other reason then the other out-of-the-box supported types only need a single value. Is there a specific reason why you are using the form properties and not the new JSON forms added in Flowable 6? The new JSON forms are a lot more flexible to define new field types etc.
thank you, once again, for your reply.
We are also using the JSON format (and another 'external form’
manager)…the fact is that we want to allow the designer (when the process
needs human interaction - UserTask) to choose either, to invoke external
forms or (if the task doesn’t need many or complicated input fields) to
define the fields directly in the User Task configuration (that’s why we
are using the Form properties). But I’ll see, if we can have a ‘design
workaround’…
Also, I would like to send you two final notes:
I’ve already forked a copy of your repository at GitHub and I am
willing to help. We’ll (the client where I am at the moment) start a
project soon and I hope that we will send you some stuff, from our
development team. But also, I’m available to help (in any way - correct,
develop, whatever)…If you need anything specific and don’t have the
’hands’to do it, don’t hesitate to contact,
Because of the project that I refer in the previous lines, I need more
info regarding your recent market approach with edorasware. If you don’t
mind, I’ll send you an invitation thru Linkedin so that we can have a ‘less
public’ discussion.
Ok cool. We always are looking for developers that can work on new features for the Flowable Engine. Just sent me a message to discuss this. About the commercial support options als just sent me a message to discuss it further.
discussion.