When implementing a Dynamic Process, there currently are three options to implement a case activity: Human Task, Service (or Integration), and Process. At least up to version 18.4.5.0.0 there is limitation when defining the interface in case of a Process Activity making that you cannot use a Business Type which is based on an XSD element, which on its turn in based on a complexType. The below describes the problem you will run into, and a suggestion of how to work-around this.
When developing XSD's for web services you may have developed the practice of defining a complexType with an element based on that complexType, for example as in the below XSD.
Reason could be that you developed with the (on-premise) SOA or BPM Suite and found this to give the best flexibility, especially when integrating with Oracle Business Rules.
However, when you base the input argument of a Structured Process on an element that on its turn is based on a complex type, you will find this does not work when using it to implement the input argument of a Process Activity. You will run in to an error similar to the following:
In the example below the "First" activity is implemented as a Process activity with name "SRElementStart".
The Dynamic Process has a start argument based on the Business Type "RequestElement" that is created using the "request" element from the XSD:
Also the Structured Process has a start argument based on "RequestElement":
For the Process activity with name "First" the process input argument is mapped to the input argument of the Structured Process:
When running this application it fails in the Start event of the Structured Process with the error mentioned at the beginning.
The problem being that when invoking the Structured Process, the Dynamic Process uses the name of the Business Type instead of the name of the argument to invoke it.
The solution is to define the input argument using a Business Type that is based on the complexType (instead of the element).
So far this is the only place where I ran into this issue. After fixing it I can map the of the Structured Process input argument backed by the complexType to a (local) Business Object backed by the element without an issue. I can also map the same Business Object back to the Dynamic Process Business Object (backed by the element) without an issue. Business Object backed by an element can be mapped 1:1 on a Business Object backed by a complexType.
You can prevent the issue by defining all your Business Types on complexTypes, or only for the input argument of Structured Processes. So far I have not found any limitations to do the first, so that probably is the easiest to do.
Many thanks to Luc Gorissen who helped my to discover the solution, and let's hope that with some next version this restriction is gone.
When developing XSD's for web services you may have developed the practice of defining a complexType with an element based on that complexType, for example as in the below XSD.
Reason could be that you developed with the (on-premise) SOA or BPM Suite and found this to give the best flexibility, especially when integrating with Oracle Business Rules.
However, when you base the input argument of a Structured Process on an element that on its turn is based on a complex type, you will find this does not work when using it to implement the input argument of a Process Activity. You will run in to an error similar to the following:
In the example below the "First" activity is implemented as a Process activity with name "SRElementStart".
The Dynamic Process has a start argument based on the Business Type "RequestElement" that is created using the "request" element from the XSD:
Also the Structured Process has a start argument based on "RequestElement":
For the Process activity with name "First" the process input argument is mapped to the input argument of the Structured Process:
When running this application it fails in the Start event of the Structured Process with the error mentioned at the beginning.
The problem being that when invoking the Structured Process, the Dynamic Process uses the name of the Business Type instead of the name of the argument to invoke it.
The solution is to define the input argument using a Business Type that is based on the complexType (instead of the element).
So far this is the only place where I ran into this issue. After fixing it I can map the of the Structured Process input argument backed by the complexType to a (local) Business Object backed by the element without an issue. I can also map the same Business Object back to the Dynamic Process Business Object (backed by the element) without an issue. Business Object backed by an element can be mapped 1:1 on a Business Object backed by a complexType.
You can prevent the issue by defining all your Business Types on complexTypes, or only for the input argument of Structured Processes. So far I have not found any limitations to do the first, so that probably is the easiest to do.
Many thanks to Luc Gorissen who helped my to discover the solution, and let's hope that with some next version this restriction is gone.
No comments:
Post a Comment