Message-ID: <1234816078.12840.1414276140450.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_12839_81592752.1414276140449" ------=_Part_12839_81592752.1414276140449 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Noticed behavior: After making manual changes to the BP= MN 2.0 xml file in the editor, some of those changes are lost upon save of = the diagram.
Workaround: Only use constructs supported by the diagra= m view when editing the BPMN directly
Although the behavior may be confusing and at times inconvenient, this i= s not a bug, but a feature. You can edit in either the dia= gram or the XML view, but in both views your are bound by the functionality= we actually support. The essence of the way this works is that ch= anges made in either view are synchronized to the other view and must there= fore be supported by both. Any change to the diagram will regenerate the BP= MN for all constructs supported.
Obviously, you can use constructs in the BPMN XML than we don't support = (and may or may not be supported in Activiti's engine), but we will not be = able to process them and will therefore drop them upon regeneration from th= e diagram to BPMN.
The easiest rule of thumb is this: if you can't do it in the process dia= gram, then you can't do it in the BPMN either, even if Activiti engine supp= orts it.
If you find a construct you can edit in the process diagram, bu= t doesn't get synced to the BPMN, then that's a bug. Please report a case l= ike this to us, by filing a Jira issue for the Desig= ner component and we will look into it. Regenerating the BPMN for the const= ructs supported and dropping non-supported output is, however, a feature.= p>