This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Use case - user has one or more activities in diagram that they wish to "wrap" in a container (i.e. If, Scope, Sequence, etc) Today - user must add the new container (either before or after the existing activity(s). Then user can move the existing activity(s) into the new contaienr. Proposal from user - Add a "Wrap Activity" context menu action on diagram activities. This is very reasonable request. However there are some limitations on what we can do in near future (particularly re multiple selection). Also there are some emerging language constructs which may make some of these use cases moot. Let's look at details ---------------------- Questions and issues: Use case - add compensation handler or add catch will be handled by the BPEL 2.0 Inovke activity itself as soon as the engine supports this behhavior. <complexType name="tInvoke"> <complexContent> <extension base="bpws:tActivity"> <sequence> <element name="correlations" type="bpws:tCorrelationsWithPattern" minOccurs="0"/> <!-- not supported by BPEL engine <element name="catch" type="bpws:tCatch" minOccurs="0" maxOccurs="unbounded"/> <element name="catchAll" type="bpws:tActivityOrCompensateContainer" minOccurs="0"/> <element name="compensationHandler" type="bpws:tCompensationHandler" minOccurs="0"/> --> <element name="toPart" type="bpws:tToPart" minOccurs="0" maxOccurs="unbounded"/> <element name="fromPart" type="bpws:tFromPart" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="partnerLink" type="NCName" use="required"/> <attribute name="portType" type="QName" use="optional"/> <attribute name="operation" type="NCName" use="required"/> <attribute name="inputVariable" type="NCName" use="optional"/> <attribute name="outputVariable" type="NCName" use="optional"/> </extension> </complexContent> </complexType> So if this is the primary use case, we will not need any new behavior, since the diagram will already support Add Catch and Add Compensation Handler to Invoke as soon as runtime supports this. If this is not the ONLY use case. If you want/need general "wrap activity" action, then the outstanding question is do you need multiple selection for this or is it good enough for the activitiy to be available on a single activity?
First, I must confess that I am not familiar with BPEL 2.0 spec and have been more at the 1.1 spec. Now coming to the point, I am not sure if I understood the statement - 'diagram will already support Add Catch and Add Compensation Handler to Invoke'. I guess I need to go and read the spec. Given my limited range of imagination, I can understand this in two ways: 1. If you need to wrap an invoke in catch block that would be supported: i.e you can create a scope and drop the invoke with in it. This feature already exists today and my guess is you did not mean this. 2. An invoke activity will automatically support catch block: i.e when you drop an invoke activity on the BPEL editor, you will automatically get a scope. I am not sure how true this would be since it is always possible to have invoke's which do not throw an exception for eg: a WSDL that only has an input and no output would not have an exception. Even if any of the above would be supported, the feature that would be more helpful is to edit an existing invoke such that it can be wrapped into a catch block. When creating a new BPEL, the problem is minimal since you have not finished the BPEL and COULD be willing to put them in place, The main problem is when editing the BPEL and especially when some one else has put the logic and all you need is to wrap the node in catch block. The wrap around an activity is not limited to catch alone. Another example is wrapping a set of activities around a while block. I guess any scoping would need this context menu feature. Regarding a single activity or multiple activity- I would request for both since in most of the cases when you are wrapping in a while block it would be multiple invokes.
Short notes: From BPEL 2.0 specification: <xsd:element name="catch" type="tCatch"> <xsd:annotation> <xsd:documentation> This element can contain all activities including the activities compensate, compensateScope and rethrow. </xsd:documentation> </xsd:annotation> </xsd:element> <xsd:complexType name="tCatch"> <xsd:complexContent> <xsd:extension base="tActivityContainer"> <xsd:attribute name="faultName" type="xsd:QName"/> <xsd:attribute name="faultVariable" type="BPELVariableName"/> <xsd:attribute name="faultMessageType" type="xsd:QName"/> <xsd:attribute name="faultElement" type="xsd:QName"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> So we have next use cases: 1. use case add invoke result: <bpws:invoke name="Invoke1"/> 2. uc: add catch for invoke result: <bpws:invoke name="Invoke1"> <bpws:catch></bpws:catch> </bpws:invoke> 3. uc add e.g. empty activity to the catch result: <bpws:invoke name="Invoke1"> <bpws:catch> <bpws:empty name="Empty1"/> </bpws:catch> </bpws:invoke> and so on... Short addition - now due to issues 79780 and 79777 there are no actions like "Add Catch"... on diagramm or navigator... I have one dummy use case when we haven't got any workaround except direct source editing: 1. create empty bpel process 2. add invoke 3. now we'd like to wrap e.g. it with scope and we can't do it It's too dummy use case but there are could be number of situations when we'd like to wrap existing part of bpel process with if, scope, while ... activities. IMHO in spite of multiple selection limitation it could be usefull to have even for single activities e.g. we'd like to wrap "big" scope with if activity - from user(my :)) point of view it's very reasonable to try to search "wrap action" to invoke it.
Implemented. Currently just single selection model is supported.
Additional point: Allow invoke wrap with "any activity" on any activity example use case: wrap with ForEach action invoked on sequence results into sequence wrapped with scope which in turn wrapped with ForEach {Sequence1} -> {ForEach1{Scope1{Sequence1}}}
done