IBM Support

BPM integration issues in modeling and transformations of business processes and services architecture

Product documentation


Abstract

The legacy BPM (Business Process Modeling) workflow imports WebSphere Modeler business models, models services in UML (Unified Modeling Language), and transforms to SCA (Service Component Architecture) and BPEL (Business Process Execution Language) consumable by IBM Integration Designer. A business model which is simply transformed to UML then to SCA/BPEL encounters errors immediately upon import into Integration Designer. A series of workarounds for importing and transformation problems as well as additional steps are presented here in order that the user may have a high level implementation of the modeled business process that is ready for deployment in BPM.

Content

The content is organized into sections dealing with problems encountered from different stages in the SOMA (Service-Oriented Modeling and Architecture) process for easier navigation to specific problem areas as follows:

  1. Services Modeling: Import Business Models, Transform Business Process to Services Model, Implement Required Interfaces, Activity Diagram, Validate the Model, Assemble the Participants
  2. Transforming Services Model to SOA (Service Oriented Architecture) and BPEL
  3. Importing SCA into IBM Integration Designer.
  4. References

1 Services Modeling

1.1 Import Business Models

  1. Import business models from zipped project interchange exported from WebSphere Modeler, or by importing existing projects (by copy) from the Modeler workspace directly. Processes in the business model get converted to UML collaborations with activities illustrating the protocol.
  2. When re-importing or opening the workspace after design has started, be sure to open the project and model in the order of dependency. Open the services model which is dependent on business models last. If not opened correctly and references are broken, close all models and projects and restart the product.

1.2 Transform Business Process to Service Model
After you have imported the business model, you create a services model using the imported business model as a specification.
  1. Create a new UML Project with a Services Design Template model.
  2. Create a new Business Process to Services Model transformation configuration with the business model as the source and the new project as the target. Set the profile to SoaML (SOA Modeling Language), and choose only the processes in the source that you want to implement by customizing the remaining ones to "Do not transform."
  3. Run the transformation.
  4. Service interfaces for port types are generated from the roles in the process. They are stereotyped classes that use or implement interfaces in the business model. The ports are stereotyped as service or request ports. Before transforming to SOA, inspect the relationships on the service interfaces. Although they correctly show a usage for required interfaces, a <<request>> stereotype flips them to realizations during transform, producing exports instead of imports. Since <<request>> and <<service>> stereotypes simplify modeling by using the same service interface on both ports, you need only show the realization. There are two workarounds:
    1. The first workaround is for architects accustomed to modeling service interface pairs, called conjugates, one for the providing interface, and one for the requiring interface. Remove the <<request>> stereotype on the port, because it interchanges the provided and required interfaces on the port if the type is stereotyped <<service Interface>>. We already have required interfaces on the request ports and don't want them changed.
    2. The second workaround is preferable since we need only one service interface and can be used on both the service and request ports, without needing a conjugate interface with opposite operations. It is simpler to model one service interface as the type for both the service port and the request port, and indicate its relationship to the business model interface (usage or implements) using the <<request>> or <<service>> stereotype on the port. Change the relationships generated by the business model to UML transform between the service interface on the request port and the interface it requires to an 'implements' rather than 'usage'. The UML to SOA sees the <<request>> stereotype, assumes only one service interface exists between the providing and required port, and flips the relationship between the appropriate one.
  5. [optional, skip if the business model has complete, typed business entities to use for sending data between services] Model the service data to be used in the parameters of the service operations. UML Primitive types are available already, but each BusinessEntity in the business model's data catalog must have a corresponding class in the service data model. One way to do this is to save the xmi business model file as a UML model emx file, remove the <<BusinessEntity>> stereotype and add the appropriate SoaML service data stereotype. SoaML supports both document-centered style (Message Type) and RPC style (Data Type) parameters. RPC style supports multiple input operations, while document-centered support one input operations. For details, see Jim Amsden's article at http://www.ibm.com/developerworks/rational/library/10/modelingwithsoaml-5/index.html.

1.3 Implement Required Interfaces
  1. We need components to implement all the process' required interfaces. Add a new package structure in the UML model for each required interface using the same package structure as the role resource in the specification model. Add a participant to the package with the same name as the interface it provides.
  2. Add a <<service>> port to the participant, and set the type to the service interface that was generated in the business process to service model transform. We already changed the usage to implements in step 1.2, so the port properties will show the provided interface.
  3. Add operations for each participant with same signature as the operations in the interfaces that their service interfaces implement.
  4. Add behaviors for each operation in each participant: either a UML opaque behavior or UML activity or sequence, with the parameters matching the operation's parameters in the same participant. Set the specification of these behaviors to this operation.
  5. [Optional] Define the behavior for opaque behaviors using language and body attributes. Note that the UML to BPEL does not generate java implementation, so you would have to set the implementation again after importing into IBM Integration Designer.

1.4 Activity Diagram
  1. Set UML Diagram preferences to align partitions horizontally for activity diagrams.
  2. For each process in the business model you selected in the transformation configuration, the business process to service model transformation generated a participant with a service port providing the service in the service interface. The behavior of the service is modeled as an activity. In the properties view for the activity, set the specification directly to the operation in the business model interface which the service interface implements. The later UML to SOA transformation step will generate a BPEL starting with a receive node.
    Note there will only be one provided service for each process. In UML, technically a participant can have multiple operations, each specifying a behavior. Regardless of their behavior type, the UML to SOA transformation will generate a BPEL starting with a receive pick node to route the incoming message. To add operations to your service interface, you will need the specified operation inside the participant. To do this, the easiest way is to delete the activity from the participant. Copy the operation under the interface in the business model's process catalog to the participant. The activity also gets copied and its specification gets set. in the properties view for the activity.
  3. If you opted to create a data model, then the operation in the participant needs to have its parameter types changed to the types in the data model.
  4. For each process that generated an activity for a participant, add an activity diagram. Tidy up the diagram manually if it is hard to read. Move decision and merge nodes to appropriate lanes. Move activity out parameter node to right side edge.
  5. Ensure the activity has parameters set corresponding to the activity specification. No change required if you did not create a data model. Ensure the input and output parameters nodes on the edge of the activity diagram also reflect the correct types and direction of the operation parameters.
  6. Change each swimlane's represents property from the businessWorker role to the <<serviceInterface>> port type which uses that role.
  7. For each Call Operation Action in the activity, change the target input pins to be the same as the port type the swimlanes represents. Hint: From the project explorer you can select all target pins from the same lane then use the properties view to set their types all at once.
  8. [Optional] Set object flow names. The business process to service model transform generates unique object flow names using unimaginative numbering. These unique names will then prompt the UML to BPEL transform to generate different local variables, when in most cases the activity's global input and output parameters will be sufficient and save memory in the deployed process.
    1. global variables: Where desired, set the object flow names to use the global variables generated by concatenating activity name + "_" + activity parameter name.
    2. Local variables: Where an object flow's source and target type are not the same type as a global variable, or your design doesn't warrant exposing temporary values to other participants, you must leave it as a local variable, and may choose a more descriptive name.
    3. Decision flows: the names of the object flows from decision nodes are also local variable names. If possible you can set all output flows to a global variable or else choose a local variable name representing both the type and the path, e.g. application_approved & application_rejected.
  9. Set decision conditions using java. Constant guards on decision output flows are all set to constant literal value true upon import to the product from WebSphere Modeler. Use language and body attributes on the UML object flows to direct decision flow. Tip: The guard in the properties view/General tab isn't editable until you go to Advanced tab, add an expression to the guard and set the language to Java.
  10. In opaque actions, use language and body field for nontrivial assignments or java snippets. Simple assignments from input object flow variable to output object flow variable are achieved with blank language and body. Loop initialization counters & test conditions can be set in name fields using lvalue:=rvalue expressions separated by ';'. Name fields cannot handle nontrivial business object assignments.
    For example, customer := application.responsibleParty does not work in the Name field, but set Language to Java and Body to customer=verifyaccount_application.getDataObject("responsibleparty");
  11. Change decision guards, and opaque actions with java implementation to replace parameter names with the prefix <activity name> + "_" + <activity parameter>. For example, change
    return (application.getInt("creditScore") <=2); to return (verifyaccount_application.getInt("creditScore") <= 2);

1.5 Validate the Model
  1. Run Model Validation. If there are behavioral feature errors, ensure you've created all the operations for the behavior in the participant, and the specifications for the behavior are inside the participant. You may disregard or disable the UML 2.2 constraints, "Behavior specified by the feature of its context classifier" in the Model Validation preferences if the participant containing the activity has only the one operation.

1.6 Assemble the Participants
The final step in the SOMA process for modeling services is to assemble the participants. You must skip these steps if you wish to continue to the next section, Transform Services Model to SOA and BPEL.
  1. Create a new participant in the implementation package of the services model (the same top level implementation package as the other participants).
  2. Create a new composite structure diagram under the assembly component.
  3. Create a service port on the assembly component.
  4. Create a delegate connector from the assembly service port to the provided service port of the participant representing the process.
  5. Drag and drop all other participants which implement the required interfaces into the assembling participant composite structure diagram.
  6. Connect the process' request ports to the service ports of the components implementing the required interfaces with a service channel.
  7. Run model validation. Verify there are no errors.

2 Transforming Services Model to SOA and BPEL
  1. Create a UML to SOA transformation configuration with only the services model as the source. Set the target to be the workspace.
  2. Run the transformation. A project for each participant providing a service is created. A project for the assembly participant which reflects the process is created. A library (java project) for each business model referenced by the UML model is created. These libraries hold the WSDLs (Web Services Description Language) generated from each service interface, and XSDs (XML Schema Definition) for each business object.

3 Importing SCA into IBM Integration Designer
  1. For each library that was generated from the UML to SOA transform, go to the properties/java build path page. In the projects tab, add the library projects holding the referenced business objects.
  2. Export the generated libraries and SCA modules to the filesystem.
  3. Import the existing projects into the IBM Integration Designer workspace.
  4. Migrate when prompted since SCA generated is version 6 and this document is targeting IBM Integration Designer 7.5.
  5. Fix warnings for import statements in WSDL files as Integration Designer doesn't accept project names. E.g. the error: "The ../../../../AccountManagementLibrary/com/jke/riskassessment/RiskAssessor.wsdl unique resource identifier is not supported in IBM Process Server" is fixed by removing the ../AccountManagementLibrary from VerifyAccountArtifacts.wsdl.
  6. Add java implementation for components with opaque behaviors.
  7. For each pair of warnings, " The module name for SCA import x is missing" and " "The target export name for SCA import CreditManagementServiceImport is missing.", select the import in the assembly, and in properties view, click on the Binding tab. Click Browse to find the matching export. This fills in both the module name and the target name.
  8. In BPEL diagrams, select receive and reply nodes and change their name from <process> to <process>Receive and <process>Reply. Where there are parallel sequences, such as after a Pick Receive node, change their names to be unique in the scope, e.g. Sequence1, Sequence2, etc.
  9. To avoid problems deploying complex BPEL on Process Server ensure the BPEL has well-formed decision nodes. Links that are generated do not work for exclusive activity branches as they are interpreted by the runtime to be parallel activities. One way around this is to remove the links and duplicate the target activity.

4 References
  1. Rational Software Architect Help topic: Considerations for modeling elements in UML activities
  2. Jim Amsden, "Modeling with SoaML, the service-oriented Architecture Modeling Language: Part 5. Service implementation" on developerWorks at: http://www.ibm.com/developerworks/rational/library/10/modelingwithsoaml-5/index.html
  3. Interpretation of UML elements by UML to SOA transform: http://publib.boulder.ibm.com/infocenter/rsahelp/v8/topic/com.ibm.xtools.transform.uml2.soa.doc/topics/rusoamap.html
  4. Rational Software Architect Tools: SOMA process: In Rational Software Architect, new model projects contain a Service Design Template with package structure, reusable elements and process notes to help follow the Service-Oriented Modeling and Architecture process.
  5. Redbook: Migrating WBI to WPS:
    http://www.redbooks.ibm.com/redbooks/pdfs/sg247416.pdf

Cross reference information
Segment Product Component Platform Version Edition
Software Development Rational Software Architect Integrations: IBM Windows 8.0.3

Product Alias/Synonym

RSA
RSAWS

Document information

More support for: Rational Software Architect for WebSphere Software
Integrations: IBM

Software version: 8.0.3

Operating system(s): Windows

Reference #: 7022402

Modified date: 2016-01-04