Community
Participate
Working Groups
When creating a new choreography diagram, you create the BPMN2 diagram which automatically creates a default 'process' element associated with the default 'internal' participant. When a choreography task is dragged onto the canvas, it gets contained within the default process. If a choreography element is created through the advanced properties associated with the canvas, the tasks are still not associated with the choreography. Also tried removing the process elements, but it throws an exception and then when showing the graphical elements it shows a warning (tooltip) message saying that the graphical object has no associated business object. The exception is: java.lang.NullPointerException at org.eclipse.graphiti.features.impl.AbstractFeatureProvider.link(AbstractFeatureProvider.java:600) at org.eclipse.graphiti.features.impl.AbstractFeature.link(AbstractFeature.java:205) at org.jboss.bpmn2.editor.core.features.AbstractBpmnAddFeature.createDIShape(AbstractBpmnAddFeature.java:85) at org.jboss.bpmn2.editor.core.features.AbstractBpmnAddFeature.createDIShape(AbstractBpmnAddFeature.java:52) at org.jboss.bpmn2.editor.ui.features.choreography.ChoreographyAddFeature.add(ChoreographyAddFeature.java:116) at org.eclipse.graphiti.internal.command.AddFeatureCommandWithContext.execute(AddFeatureCommandWithContext.java:76) at org.eclipse.graphiti.internal.command.GFPreparableCommand.doExecute(GFPreparableCommand.java:37) at org.eclipse.emf.transaction.RecordingCommand.execute(RecordingCommand.java:135) at org.eclipse.graphiti.ui.internal.editor.GFWorkspaceCommandStackImpl.execute(GFWorkspaceCommandStackImpl.java:52) at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:219) at org.eclipse.graphiti.ui.internal.editor.GFWorkspaceCommandStackImpl.execute(GFWorkspaceCommandStackImpl.java:39) at org.eclipse.graphiti.internal.command.CommandExec.executeCommand(CommandExec.java:74) at org.eclipse.graphiti.features.impl.AbstractFeatureProvider.addIfPossible(AbstractFeatureProvider.java:337) at org.eclipse.graphiti.features.impl.AbstractFeature.addGraphicalRepresentation(AbstractFeature.java:108) at org.jboss.bpmn2.editor.core.features.AbstractCreateFlowElementFeature.create(AbstractCreateFlowElementFeature.java:59) at org.eclipse.graphiti.features.impl.AbstractCreateFeature.execute(AbstractCreateFeature.java:100) at org.eclipse.graphiti.internal.command.GenericFeatureCommandWithContext.execute(GenericFeatureCommandWithContext.java:64) at org.eclipse.graphiti.internal.command.GFPreparableCommand.doExecute(GFPreparableCommand.java:37) at org.eclipse.emf.transaction.RecordingCommand.execute(RecordingCommand.java:135) at org.eclipse.graphiti.ui.internal.editor.GFWorkspaceCommandStackImpl.execute(GFWorkspaceCommandStackImpl.java:52) at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:219) at org.eclipse.graphiti.ui.internal.editor.GFWorkspaceCommandStackImpl.execute(GFWorkspaceCommandStackImpl.java:39) at org.eclipse.graphiti.internal.command.CommandExec.executeCommand(CommandExec.java:74) at org.eclipse.graphiti.ui.internal.command.CreateModelObjectCommand.execute(CreateModelObjectCommand.java:52) at org.eclipse.graphiti.ui.internal.editor.EmfOnGefCommand.execute(EmfOnGefCommand.java:58) at org.eclipse.graphiti.internal.command.GFPreparableCommand2.doExecute(GFPreparableCommand2.java:37) at org.eclipse.emf.transaction.RecordingCommand.execute(RecordingCommand.java:135) at org.eclipse.emf.workspace.EMFCommandOperation.doExecute(EMFCommandOperation.java:119) at org.eclipse.emf.workspace.AbstractEMFOperation.execute(AbstractEMFOperation.java:150) at org.eclipse.core.commands.operations.DefaultOperationHistory.execute(DefaultOperationHistory.java:511) at org.eclipse.emf.workspace.impl.WorkspaceCommandStackImpl.doExecute(WorkspaceCommandStackImpl.java:208) at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:165) at org.eclipse.graphiti.ui.internal.editor.GFWorkspaceCommandStackImpl.execute(GFWorkspaceCommandStackImpl.java:47) at org.eclipse.emf.transaction.impl.AbstractTransactionalCommandStack.execute(AbstractTransactionalCommandStack.java:219) at org.eclipse.graphiti.ui.internal.editor.GFWorkspaceCommandStackImpl.execute(GFWorkspaceCommandStackImpl.java:39) at org.eclipse.graphiti.ui.internal.editor.GFCommandStack.execute(GFCommandStack.java:108) at org.eclipse.gef.dnd.AbstractTransferDropTargetListener.handleDrop(AbstractTransferDropTargetListener.java:339) at org.eclipse.gef.dnd.TemplateTransferDropTargetListener.handleDrop(TemplateTransferDropTargetListener.java:115) at org.eclipse.gef.dnd.AbstractTransferDropTargetListener.drop(AbstractTransferDropTargetListener.java:183) at org.eclipse.jface.util.DelegatingDropAdapter$3.run(DelegatingDropAdapter.java:211) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:49) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:175) at org.eclipse.jface.util.DelegatingDropAdapter.drop(DelegatingDropAdapter.java:209) at org.eclipse.swt.dnd.DNDListener.handleEvent(DNDListener.java:90) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1267) at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1061) at org.eclipse.swt.dnd.DropTarget.drag_data_received(DropTarget.java:371) at org.eclipse.swt.dnd.DropTarget.Drag_Data_Received(DropTarget.java:251) at org.eclipse.swt.internal.gtk.OS._gtk_drag_get_data(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_drag_get_data(OS.java:6443) at org.eclipse.swt.dnd.DropTarget.drag_drop(DropTarget.java:416) at org.eclipse.swt.dnd.DropTarget.Drag_Drop(DropTarget.java:258) at org.eclipse.swt.internal.gtk.OS._gtk_main_do_event(Native Method) at org.eclipse.swt.internal.gtk.OS.gtk_main_do_event(OS.java:8163) at org.eclipse.swt.widgets.Display.eventProc(Display.java:1239) at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2224) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3169) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2629) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2593) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2427) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:670) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:663) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) at org.eclipse.equinox.launcher.Main.main(Main.java:1383) Gary Brown added a comment - 22/Jul/11 9:52 AM Suggestion: When creating a process, it normally has to be associated with a participant/pool (especially when in a collaboration diagram). Whereas a choreography does not get defined in a visual container. So wondering whether the default location for nodes dragged on to the canvas should be a choreography, instead of a "Process for Internal". Might need to see whether this would impact jBPM. But if practical, then provides a simple short term solution to the problem. Robert (Bob) Brodt added a comment - 22/Jul/11 11:14 AM Good idea Gary, at least it will do until (and if) we add support for different diagram types (a multi-tab editor). Gary Brown added a comment - 22/Jul/11 12:17 PM If Kris has no objections to the solution, any chance this could be fixed sooner - currently on the schedule it is down as next year Feb (I think) Brian Fitzpatrick added a comment - 22/Jul/11 5:25 PM Hey Gary - as a BPMN2 n00b, can you put together a sample or more concrete reproductive steps so I can better understand this one?
Hi Brian Sorry for the late response, somehow missed the notification email. Steps to reproduce are: 1) Create a blank diagram 2) View the properties (advanced tab) associated with the canvas, this will include a Collaboration element with an 'internal' participant, and a Process element for that internal participant 3) When dragging start/end events and a Choreography Task on to the canvas, these are automatically contained with the Process element. So this is the basic problem - elements that are being added to the diagram to represent a choreography are being contained within a Process. So the next step is to create a Choreography element, using the context menu on the advanced properties to 'add root property->Choreography'. However when dragging a Choreography Task onto the canvas, it still places it into the default process. So we need a means of the tool understanding where is should place dragged components, when there are multiple potential containers. When I create a pool and then drag a task into it, it automatically creates a 'process' for that pool and contains the task within it. So I think my previous suggestion is sensible - that the default container should actually be a choreography (for now). There may be cases where someone simply wants to define the behaviour of a single process and therefore not create a pool - but it seems easy enough to create a pool per participant/process, and anything outside of the pool is collaboration/choreography. Let me know if further clarification is required.
Hi Bob Yes adding a summary to the bugzilla would be good. +1 to your comment on the NewFileWizard. Is this something that could be done in the near future? I will need play with the latest version of the editor to confirm the validation aspect, as last time I tried it I was able to drag a ChoreographyTask onto the canvas, which resulted in it being placed in the default process - so that should be invalid. Regards Gary ----- Original Message ----- > Hi Gary, we should probably add this conversation to bugzilla. > > ----- Original Message ----- > > Hi Bob > > > > > > > > > > > > It makes sense to use a Choreography instead of a > > > > > Collaboration > > > > > as > > > > > the default, "internal" container since Choreography extends > > > > > Collaboration anyway. > > > > > > > > Agree - so by default items would be added to the default > > > > choreography, and if a user wishes to create a process model, > > > > they > > > > create a pool (and participant) with the relevant process > > > > details. > > > > The only situation we need to consider how to handle is where a > > > > new > > > > user simply drags process model components onto the canvas (and > > > > therefore choreography) - and then tries to execute the model > > > > on > > > > jBPM5? > > > > > > not quite...when the default Choreography is created, it also > > > creates > > > a Participant which is associated with the default Process. So, a > > > fresh file with a single task in it looks like this: > > > > > > <?xml version="1.0" encoding="UTF-8"?> > > > <bpmn2:definitions > > > 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" > > > id="Definitions_1"> > > > <bpmn2:choreography id="Choreography_1"> > > > <bpmn2:participant id="Participant_1" name="Internal" > > > processRef="Process_1"/> > > > </bpmn2:choreography> > > > <bpmn2:process id="Process_1" name="Process for Internal"> > > > <bpmn2:task id="Task_1" name="Task Name"/> > > > </bpmn2:process> > > > <bpmndi:BPMNDiagram id="BPMNDiagram_1"> > > > <bpmndi:BPMNPlane id="BPMNPlane_Process_1" > > > bpmnElement="Process_1"> > > > <bpmndi:BPMNShape id="BPMNShape_Task_1" > > > bpmnElement="Task_1"> > > > <dc:Bounds height="50.0" width="110.0" x="450.0" > > > y="220.0"/> > > > </bpmndi:BPMNShape> > > > </bpmndi:BPMNPlane> > > > </bpmndi:BPMNDiagram> > > > </bpmn2:definitions> > > > > > > Does that look about right? > > > > No this has the same issue as now - that components dragged onto > > the > > canvas automatically get associated with this default process. So > > its possible to (for example) drag a ChoreographyTask onto the > > canvas and it will also go into the default process. > > > > However if you drag a pool onto the canvas, I believe any > > components > > dragged into the pool get contained within the process created > > against that pool. > > > > So what I was suggesting is that instead of having a default > > process, > > we have a default choreography. So by default anything dragged onto > > the canvas will be associated with the choreography, and uses then > > create processes as before - so to make a 'valid' model really a > > user would have to use pools. > > > > Neither the current or my suggested approach is ideal, as it still > > results in the ability for a user to drag invalid components into > > containers - although some validation can be done at a later stage > > to overcome that. > > > > Possibly the best (and easiest) solution would be: > > > > (1) when offering the ability to create a BPMN2 diagram, allow the > > user to select whether it should default as a choreography or > > process. > > I like the idea of being able to specify a diagram type in the New > File wizard. > It should probably be expanded to include the other types of diagram > types as well > and provide appropriate, long-winded descriptions of each type, > possibly with a visual > to go along with the description :-) > What do you think? > > > (2) provide validation to ensure the process and choreography > > containers cannot contain invalid components, to ensure the user > > doesn't mistakenly drag components onto the wrong container. > > The editor already disallows dropping toolpalette items on invalid > targets, > so I don't think further validation will be required. > > > > > > > > > > > > > > > > > > > So, this would make the main canvas the > > > > > default "pool" (ocean?) which would be the default > > > > > Participant. > > > > > > > > Not sure I understand - the canvas would not be associated with > > > > a > > > > pool, it would be associated with the choreography. A pool and > > > > participant would only be created if a user drags a pool onto > > > > the > > > > canvas? > > > > > > OK, now I'm really confused ;) There really is no "Pool" element > > > defined in the spec (or the model) it's just a graphical > > > representation for the "Participant" element, correct? In the > > > case > > > where the user creates a new bpmn diagram with the editor and > > > builds > > > up a process, the editor canvas represents the default > > > Participant > > > (pool). > > > > > > > > > > > > The > > > > > problem is that when you create a new Pool, it also creates a > > > > > new > > > > > Process but the editor only creates one bpmndi:BPMNDiagram > > > > > for > > > > > the > > > > > first (default) process and places all new elements in that > > > > > diagram, > > > > > regardless of which Process the bpmnElement is contained. > > > > > > > > I don't see a single BPMNDiagram as being a problem, as it is > > > > possible to have choreographies between pools of process models > > > > (not > > > > that I think these are good diagrams) - so the diagram can > > > > include > > > > elements from different parts of the model. The diagram > > > > shouldn't > > > > be > > > > just associated with the first process anyway. > > > > > > OK, sounds reasonable I guess...at some point we will want to > > > make > > > this a multipage editor so that each page is a separate > > > BPMNDiagram, > > > right? > > > > Eventually, but I think this is a separate issue. This issue is > > about > > how to ensure components dragged onto a canvas are placed into the > > correct container. > > > > Regards > > Gary
Tried out the version on the update site (http://download.eclipse.org/bpmn2-modeler/site/), which is from July, and if I create a new diagram, and drag a ChoreographyTask onto the canvas, and then go to the Advanced properties for the canvas, the ChoreographyTask is contained under the Process associated with the internal participant. If this behaviour has changed in the latest version, would it be possible to rebuild the update site, and I will give it another go.
I believe this has been resolved. Gary, can you verify?
I can verify that this has been fixed.
Yay :)
