Is there a replacement for "activiti:formProperty"

[Michael Oberwasserlechner]

Hi,

after talking to Bernd at the JAX, we decided to migrate from "Activiti" to "Camunda bpm".

The Activiti Modeler supports adding a form properties to events or user tasks in a simple way. Right now I have not found any thing like that in your modeler.

We use those build-in form properties to render simple forms in our own GWT widgets.

I looked at the roadmap and found the feature "Taskforms for rapid prototyping".
Is this meant as the replacement?

Is it possible to add such form-properties directly in xml?

Thx,
Michael

[Bernd Rücker (camunda)]

Hi Michael.

First: Welcome to camunda BPM :-)

You are actually right - this is not yet implemented in the camunda
modeler. But you can easily add that manually to the XML - the modeler
should not remove it if you use it afterwards.

We are currently discussing what exactly we want to do for task forms /
rapid prototyping. The form properties seem a bit too limited to be usable
(so we haven't yet decided if we support them and if yes only for "legacy"
or as "the recommended approach"). We for example have added "generic
forms" in the new HTML 5 tasklist which just can show and create any
variable you like - pretty handy for rapid prototyping already. Our
customer GFI for example encoded JSON definitions in the formKey (see
http://de.slideshare.net/elsvene1/jax-fallmanagementpublic, slide 72) - so
there are a couple of different approaches.
Could you maybe briefly describe how you use the form properties? That
would be viable input to the discussion on our side.

Thanks and cheers
Bernd

-----Urspr�ngliche Nachricht-----
Von: camunda-...@googlegroups.com
[mailto:camunda-...@googlegroups.com] Im Auftrag von Michael
Oberwasserlechner
Gesendet: Dienstag, 30. April 2013 10:58
An: camunda-...@googlegroups.com
Betreff: Is there a replacement for "activiti:formProperty"

--
You received this message because you are subscribed to the Google Groups
"camunda BPM users & process application developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to camunda-bpm-us...@googlegroups.com.
To post to this group, send email to camunda-...@googlegroups.com.

[Michael Oberwasserlechner]

Hi Bernd,

Your "generic form" approach sound interesting. Are there any resources or examples yet? Are those definitions accessible by the formService or another API?

How do we use the form properties?

We use the engine's formService to get the form definition, convert it to our own parameter definition and render it to our tasklist. The widget type is defined by the formProperty's attribute "type".

StartFormData formData = this.activitiFormService.getStartFormData(processDefinitionId);
TaskFormData formData = this.activitiFormService.getTaskFormData(taskId);

FormData contains only a List of FormProperties, therefore complex layouts are not possible, but at the moment that works for us.

I'm not sure if this helps. If you need more information, I might able to take some screenshots and more code samples or show you in one of your upcoming meetups. (e.g. Vienna on May 16th).

Want do we need?

I have to discuss this with my collegues in more detail but I think we need to differ between roles and use cases.

A (technical) consultant should have a very easy interface for simple form building. e.g. as part of a POC. They should not have to write a html or jsf form template, because for a simple use case the "form property" approach is good enough. 

Maybe its possible to introduce a form builder creating your "generic form"s but using a simple ui in the modeler. For more complex forms I would prefer a approach like you did it in http://camunda.org/get-started/developing-process-applications.html#taskform, because its very flexible.

We integrated Activiti only half a year a ago, therefore we have not that much experience in process modeling, so I'm thankful for any discussion on this one.

Thx and cheers,

Michael

[Bernd Rücker (camunda)]

Hi Michael.

 

Thanks already. For me it would be interesting how complex the forms are and what role designs that in your approach. And what you are maybe missing using the form properties. And why simple HTML forms do not work in that case.

 

For the generic forms: use the tasklist of camunda BPM 7.0 and start a process instance or work on a task which has no formKey configured. Then you will see the generic form. For clicking through a process model this might be sufficient. Or what do you think? We are pretty eager to hear feedback on this.

 

So actually what I try to figure out what

-          Use cases (prototyping, productive generic forms with auto-layout, productive forms with real form builder, …)

-          Roles (developer, consultant without HTML knowledge, …)

-          Tool support (XML Editor, camunda modeler with simple table as with the form properties, form builder, …)

We have for the UI integration and what would be the best shot to address that within camunda BPM.

 

Hope that gets clearer? I unfortunately have to write a estimation and offer right now – so just a short answer (but at least one in the time I am procrastinating ;-)).

 

Cheers

Bernd

[Michael Oberwasserlechner]

Hi Bernd,

Its getting clearer :)

Right now I have to stop the fun stuff and do something else. I hope to get back on this next week, work through your tips and give you an update.

Thanks again.

Michael

I will look at that after my vaccation next week

[in...@msiebers.de]

Hi Bernd,
I'm Michael from Zalando, we wrote some Emails.

The posts are very interesting, and some topics are very equal to that what we want to to. I'm currently working on a HTML5 Platform (AngularJS), very close to the takslist and we want do generate complex frorms with panels, tables and tabs.

But to get this possible we have to enrich the bpmn file. Now you wrote two things to this. The first one is do include a JSON as a fromKey.
The second thing was to include own XML afterwords? But both I didn't got handeld.

Hier is a example what i try but the modeler throws exceptions:

<bpmn2:userTask id="UserTask_1" activiti:assignee="John" name="User Task">
<bpmn2:incoming>SequenceFlow_4</bpmn2:incoming>
<bpmn2:outgoing>SequenceFlow_3</bpmn2:outgoing>
<bpmn2:myFromTag>
<bpmn2:panels>
<bpmn2:panel>
<bpmn2:fields>
<bpmn2:field name="Feld 1" id="field1">
<bpmn2:validation></bpmn2:validation>
</bpmn2:field>
</bpmn2:fields>
</bpmn2:panel>
<bpmn2:panel>
<bpmn2:fields>
<bpmn2:field name="Feld 2" id="field2">
<bpmn2:validation></bpmn2:validation>
</bpmn2:field>
</bpmn2:fields>
</bpmn2:panel>
</bpmn2:panels>
</bpmn2:myFromTag>
</bpmn2:userTask>

[Bernd Rücker (camunda)]

Hi Michael.

Welcome to the camunda BPM forum :-) Cool to have you around here...

For the XML: You have to stick to the correct namespace. Hence if you want
to introduce own attributes they have to have their own namespace.
Otherwise validation against the schema will fail and the modeler cannot
work correctly (as you experienced :-)). See for example
https://app.camunda.com/confluence/display/foxUserGuide/Use+custom+BPMN+ex
tension+elements.

So it should more look like:

<bpmn2:userTask id="UserTask_1" activiti:assignee="John" name="User Task">
<bpmn2:incoming>SequenceFlow_4</bpmn2:incoming>
<bpmn2:outgoing>SequenceFlow_3</bpmn2:outgoing>

<bpmn2:extensionElements>
<zalando:panels>
<zalando:panel>
<zalando:fields>
<zalando:field name="Feld 1" id="field1">
<zalando:validation></bpmn2:validation>
</zalando:field>
</zalando:fields>
</zalando:panel>
<zalando:panel>
<zalando:fields>
<zalando:field name="Feld 2" id="field2">
<zalando:validation></bpmn2:validation>
</zalando:field>
</zalando:fields>
</zalando:panel>
</zalando:panels>
</bpmn2:extensionElements>
</bpmn2:userTask>

The extensionElements is still BPMN spec - within you are free to do
whatever you like (but you have to stick to namespace hell :-)).

Cheers

Bernd

-----Urspr�ngliche Nachricht-----
Von: camunda-...@googlegroups.com
[mailto:camunda-...@googlegroups.com] Im Auftrag von

in...@msiebers.de
Gesendet: Dienstag, 30. April 2013 15:44

An: camunda-...@googlegroups.com
Cc: 'Michael Oberwasserlechner'

Betreff: Re: Is there a replacement for "activiti:formProperty"

[in...@msiebers.de]

Hi Bernd,
Thanks for your answer. I didn't had the time for trying out this last week. No I have the following problem.

If i want to include a simple extensionElement like the following, i can't run the projekt in jboss.

<bpmn2:userTask id="UserTask_1" activiti:assignee="John" name="User Task">
<bpmn2:incoming>SequenceFlow_4</bpmn2:incoming>
<bpmn2:outgoing>SequenceFlow_3</bpmn2:outgoing>

<bpmn2:extensionElements></bpmn2:extensionElements>
</bpmn2:userTask>

The error:

12:03:16,378 SEVERE [org.camunda.bpm.engine.impl.interceptor.CommandContext] (ServerService Thread Pool -- 202) Error while closing command context: org.camunda.bpm.engine.ProcessEngineException: cvc-complex-type.2.4.a: Invalid content was found starting with element 'bpmn2:extensionElements'. One of '{"http://www.omg.org/spec/BPMN/20100524/MODEL":outgoing, "http://www.omg.org/spec/BPMN/20100524/MODEL":ioSpecification, "http://www.omg.org/spec/BPMN/20100524/MODEL":property, "http://www.omg.org/spec/BPMN/20100524/MODEL":dataInputAssociation, "http://www.omg.org/spec/BPMN/20100524/MODEL":dataOutputAssociation, "http://www.omg.org/spec/BPMN/20100524/MODEL":resourceRole, "http://www.omg.org/spec/BPMN/20100524/MODEL":loopCharacteristics, "http://www.omg.org/spec/BPMN/20100524/MODEL":rendering}' is expected. | load-approval.bpmn | line 17 | column 34

The namespaces:

<bpmn2:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:activiti="http://activiti.org/bpmn" xmlns:bpmn2="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" xsi:schemaLocation="http://www.omg.org/spec/BPMN/20100501/BPMN20.xsd" xmlns:zalando="http://www.zalando.de/bpmn" id="_PFHy0KHxEeKieY6lCgTIRA" targetNamespace="http://activiti.org/bpmn">

Maybe you can help me. It must be a problem with the namespaces. I tried to find the extensionElements in http://www.omg.org/spec/BPMN/20100501/BPMN20.xsd and http://www.omg.org/spec/BPMN/20100501/BPMNDI.xsd. But I could't find a extensionElements therein the schema.

Cheers,
Michael

[Bernd Rücker (camunda)]

Hi Michael.

The element is correct - I am sure about that. But I think the order makes
a difference. Have you tried to put the extensionElements at first:

<bpmn2:userTask id="UserTask_1" activiti:assignee="John" name="User Task">

<bpmn2:extensionElements></bpmn2:extensionElements>

<bpmn2:incoming>SequenceFlow_4</bpmn2:incoming>
<bpmn2:outgoing>SequenceFlow_3</bpmn2:outgoing>

</bpmn2:userTask>

That should actually work.

Cheers
Bernd

-----Urspr�ngliche Nachricht-----
Von: camunda-...@googlegroups.com
[mailto:camunda-...@googlegroups.com] Im Auftrag von
in...@msiebers.de

Gesendet: Mittwoch, 15. Mai 2013 12:05
An: camunda-...@googlegroups.com
Cc: in...@msiebers.de; 'Michael Oberwasserlechner'

Betreff: Re: Is there a replacement for "activiti:formProperty"

[mhue...@braintags.de]

Hi,
we are already interested in which kind the form-data will be reapplied to camunda.

Our Use Cases will mainly address customized web-pages with forms or other parameter-transport, into the process-data.
That´s a task our web-developer will use to build the webpages.

So we need a way to specify parameters required to a task. Type of data
may help to show a better form to the user.
A prebuilt Rendering-Engine would lack most of the features we need to build up those pages.

The current formProperty, as in activiti, would be suffice for this job.

But i think, to handle complex forms, there should be a way to let those form-properties depend on each other.
Therefore we could show form-inputs in case a specific value is selected (like radio-buttons) or can show better validation-information.

I don´t know if its currently implemented (in either camunda BPM or activiti) but a validation mechanism would be nice too, with a failure event to reshow current usertask/form or do something else.

Cheers
Martin