Iterative development in WebSphere Business Modeler and WebSphere Integration Developer

Keeping your business processes in sync as they change over time

IBM® WebSphere® Business Modeler and IBM WebSphere Integration Developer are tools used for developing, assembling, and testing business processes, but because they are used by different roles (business analysts and integration developers, respectively), it's possible for the models in one environment to get out of sync with the models in the other environment. This article looks at how you can keep the business models in both tooling environments consistent with each other as the models evolve over time. This content is part of the IBM Business Process Management Journal.

Share:

Marc Fasbinder, Consulting I/T Specialist, IBM

Photo of Marc FasbinderMarc Fasbinder is an I/T Specialist at IBM with the WebSphere Technical Sales team in Southfield, Michigan.



04 December 2008

Also available in Chinese

Introduction

IBM® WebSphere® Business Modeler (hereafter called Modeler) is a tool used by non-technical business analysts to model business processes. Through simulation and analysis, Modeler enables the optimization of a business process. The optimized process can then be exported as WS-BPEL, XSD, WSDL and other constructs, into IBM WebSphere Integration Developer, which is the tool used by I/T personnel whose role is that of integration developer. An integration developer can then assemble and test the business process before deploying it to IBM WebSphere Process Server.

This article looks at how to keep the models in both tooling environments in sync with each other as the models evolve over time.


Modeling lifecycle

In an ideal world, a business analyst creates a model to express what a process needs to do. The model is handed over to an I/T person who then defines how to make it happen. For example:

  • Using Modeler, the business analyst models the current state, or the "as-is" process.
  • The business analyst uses simulation and analysis to create a future state, or a "to-be" version of the model.
  • An I/T technician takes ownership of the model, adds in technical details, then exports the updated model from Modeler to WebSphere Integration Developer.
  • An integration developer makes technical updates to the model, unit tests, then exports the model to an EAR file for deployment to the test and production servers.

In the real world, the lifecycle is not always as clean. For example, after the model is exported from Modeler to WebSphere Integration Developer, a late change request from the line of business might drive the need to change the business model. Or, the integration developer might need to make changes to the WS-BPEL model, making it no longer match the business model. In other words, rather than the model export being a one-time event, an iterative development cycle might be used.

There is also the scenario of round-tripping; even if the ideal lifecycle is followed, at some future time there will be updates to the model after the process is deployed. For example:

  • Version 1 of the process is placed into production.
  • WebSphere Business Monitor gathers business metrics as the process runs.
  • Monitoring results are exported from WebSphere Business Monitor with the observed metrics, such as times for tasks, percentages for decisions, and so on.
  • The initial "to-be" model is now the current “as-is” state. The monitoring result is imported into Modeler to update the business model with the observed business metric values.
  • Simulation and analysis is performed to create a new (Version 2) "to-be" model.

If the Version 2 model was simply exported to WebSphere Integration Developer, any of the technical updates that were made to the BPEL model would be lost.

In each of these cases, one of the models evolved independently of the other. A mechanism is therefore needed to keep the two models in sync with each other. Fortunately, the 6.1 version of the WebSphere BPM stack includes functionality to help you keep the models in Modeler and WebSphere Integration Developer synchronized.

Initial business model

The scenarios in this article use a simple model that describes the process for new employee on-boarding. The downloadable project file included with this article includes both as-is and to-be versions of this employee on-boarding business process. The to-be version is ready for export to WebSphere Integration Developer. To explore the initial model, import the .mar file included with this article into Modeler:

  1. Download the sample file included with this article.
  2. Start WebSphere Business Modeler.
  3. Right-click in the whitespace of the project tree, and select Import...
  4. Ensure that WebSphere Business Modeler project (.mar, .zip) is selected, then click Next.
  5. Click Browse..., navigate to the folder where you downloaded the sample, then click OK.
  6. Select Onboarding Modeling Project.mar then click Finish.
  7. When you see the message "Import finished successfully," click OK.

The to-be process, shown in Figure 1, works like this:

  • Capture New Hire Information is a local human task during which Human Resources records details about the new hire.
  • Add To Payroll System is a task that runs automatically to add the employee information into the payroll system.
  • Assign Office Space is a local human task during which Office Administration decides what desk or office will be assigned to the new hire.
  • Apply Location Rules is a local business rules task that uses work location to determine whether the employee will get a parking spot.
  • Assign Parking Space? is a simple decision that controls the flow of the process, based on the results of the business rule.
  • Assign Parking Space is a local human task during which Office Administration selects the parking space for the new employee, if the decision had been evaluated to true.
  • A merge element then brings both the yes and no outputs from the decision back to one single path.
  • Assign Phone is a local human task during which Telecommunications assigns a telephone extension to the new employee.
  • Grant Network Access is a local human task during which Network Security creates a user ID and password for the employee.
  • Schedule Training is a local task that automatically assigns the employee to standard company training.
  • Generate Summary of New Hire Details is a local task during which an automatic service generates a summary report for the new employee’s manager.
Figure 1. Onboarding business model
Figure 1. Onboarding business model

After exploring the business model, export it to WebSphere Integration Developer to generate the WS-BPEL, XSD, WSDL and other artifacts needed for run time:

  1. Right-click Onboarding - ToBe and select Export...
  2. Select WebSphere Integration Developer for the export target, and click Next.
  3. Enter a directory for exporting. Ensure that Export Specific Elements is selected, and that only Onboarding - ToBe is selected for exporting, then click Next.
  4. Accept all of the defaults on the screen, then click Next.
  5. You will see a list of everything that will be included in the export. Click Finish.
  6. When you see the message "Export finished successfully," click OK.

You can now import the project interchange into WebSphere Integration Developer. As a default, Modeler appends a time and date string to the end of the project interchange name so you can easily tell when it was exported. To import the project interchange file:

  1. Start WebSphere Integration Developer.
  2. Right-click in the empty area of the whitespace of the business integration project explorer, and select Import...
  3. Select Other - Project Interchange, then click Next.
  4. For the “From zip file” field, click Browse, then navigate to the directory where you exported the project from Modeler. Click to select the .zip file for the Modeler export, then click Open.
  5. Click Select All, then click Finish.
  6. All three projects import into WebSphere Integration Developer. Wait until the Building Workspace indicator reaches 100%.

Three projects were imported into your workspace:

  • OnboardingModelingProject_lib: A library project containing the data types and interfaces. The business process used a single business item throughout, resulting in one single data type. An interface was generated for each of the tasks.
  • OnboardingModelingProject_impl: A module that references OnboardingModelingProject_lib. This module contains the implementations for the three automatic steps, which were transformed into Java™ components. The integration developer would be responsible for implementing these components.
  • OnboardingModelingProject: A module that references OnboardingModelingProject_lib. This module contains the BPEL process, rule group and rule logic for the process.

When exporting from Modeler, you could have selected an option to put all of these elements into a single project, but separating them (the recommended practice) makes it is easier to make changes. For example, if you have deployed the modules and you need to update one of the Java components, this arrangement would enable you to redeploy the Java components, without having to redeploy the process.

The WS-BPEL representation of the process (Figure 2), is similar to the business model in that there are steps which are wired together, along with conditional branching logic. The business model was used for documentation and process improvement, while the BPEL version is executable. The process is ready to run, but first the Java components must be completed.

Figure 2. BPEL process edited in WebSphere Integration Developer
Figure 2. BPEL process edited in WebSphere Integration Developer

Update scenarios

When the project has been exported from Modeler and imported into WebSphere Integration Developer, there is a possibility that updates could be made to either model, following one of three scenarios:

  • Technical update: Updates are made to technical attributes in the BPEL model while the integration developer completes the implementation.
  • Late update: Updates are made in the business model, after it has been exported.
  • Round-trip update: The business model evolves after the system has been in production, and the technical implementation needs to be updated.

Next, each of these scenarios will be examined in detail.

Technical update

Not every attribute available in WebSphere Integration Developer can be generated by Modeler. For this reason, you need to do some work on most of the models you export before the solution is complete and ready to run. In this example, the WS-BPEL process is complete, but the Java components need some work before they can be used.

Update the Java components

  1. In the OnboardingModelerProject_impl module, expand the Business Logic folder, then expand Java Usages, and processes/onboarding.
  2. Double-click AddToPayrollSystemImpl to open it in the Java editor.
  3. Scroll to the bottom and replace this line:
    //TODO Needs to be implemented
    with:
    System.out.println("Adding to payroll...");
  4. Change the line:
    return null
    with:
    return Input
  5. Save the changes.

The last lines of AddToPayrollSystemImpl.java should now look similar to Listing 1.

Listing 1. AddToPayrollSystemImpl.java (partial listing)
public commonj.sdo.DataObject AddToPayroll(commonj.sdo.DataObject Input)  {
	    System.out.println("Adding to payroll...");
		return Input;

Repeat this procedure for GenerateSummaryImpl and ScheduleTrainingImpl. If you wish to test it, you can now deploy and run the process.

Update the business rule

Suppose that, as the integration developer, you find that the business analyst forgot to include a location in the definition of the business rule. You can update the rule like this:

  1. In the OnboardingModelingProject, expand the Business Logic folder, then expand Rule Logic and processes/onboarding. Double click applyRules to edit the rule set.
  2. In the rules editor, scroll down to the Rules section. There are five existing rules, three of which are based on a rules template. Create a new rule from a template by clicking the add template rule icon add template rule icon. A list of templates that you can choose from will display. Select LocationParkingTemplate, which is the only option in this case. A new rule named Rule6 is added at the bottom of the list.
  3. On the first line for the Rules.Input.Location, click Enter Value, then type in a city name, such as Ann Arbor.
  4. On the second line for Rules.Output.Parking, click Enter Value, then type in Yes.
  5. The rule should now look like Figure 3. Save the changes.
    Figure 3. Updated business rule
    Figure 3. Updated business rule
  6. The business rule is now updated. Close the rules editor.

Update the business process

Suppose you discover that there is a quirk with the payroll system, where a new employee cannot be added until an office space is assigned. You must change the sequence of the two steps in the process in order for the payroll service to work properly.

  1. Select the link between Add To Payroll System and Assign Office Space, then click the delete key to delete it.
  2. Move the human task Assign Office Space to the side.
  3. Click the link flowing out from Assign Office Space to select it. A dot will appear at the top and bottom so that you can move it. Click and hold the top of the connector, and move it so that it now connects from Add To Payroll System to Apply Location Rules.
  4. Click the link flowing out from Capture New Hire Information to select it. Click the bottom of the link and move it on top of Assign Office Space.
  5. Add a link from Assign Office Space to Add To Payroll System.
  6. Move the tasks to line them up, or right-click and select Arrange Parallel Activities Contents.

The sequence of the two tasks is now reversed, as shown in Figure 4.

Figure 4. Updated process
Figure 4. Updated process

Additionally, you determine that it would be more efficient to run the last two automatic activities in the same transaction.

  1. Click on the invoke named Schedule Training, then click the Properties tab and then the Server sub-tab on the side.
  2. Select the radio button for Participates. This will indicate not to commit the current transaction after the activity completes.
  3. Click on Generate Summary of New Hire Details, and navigate to the Server sub-tab in the properties to verify that Commit After is selected. This tells the server to commit the current transaction after this activity completes.

The process is now updated. Save the changes, and close the process editor.

Synchronize the models

Changes have been made to the implementation model in WebSphere Integration Developer. This means that the model is no longer in sync with the business model, and so the two must now be resynchronized.

  1. Right-click OnboardingModelingProject, and select Synchronize with Modeler Export...
  2. In the Synchronize window, click Browse... and select the project interchange file you originally exported from Modeler, then click Next.
  3. You will see projects in the interchange file and the projects in the workspace to be compared. Click Synchronize to see a list of changes. If you are prompted about synchronization information, click OK to clear it.
  4. You will see several workspace changes, indicating that you’ve made changes to the workspace since you first imported the project interchange. Click Commit.
  5. You will be prompted that a change report has been generated. This is the file you will need to send back to Modeler. Click Yes to export this file.
  6. In the wizard that pops up, the module will be automatically selected for you. Click Browse... to select a file in which to store the changes. This file must have an extension of .zip. Click Finish, then navigate to the directory you selected to confirm that the new file exists. If your system does not have enough to run both tools at the same time, you can now close WebSphere Integration Developer to save on memory.
  7. Bring up Modeler so you can apply the updates. Make sure you are in WebSphere Process Server mode. The context menu option you need is only active in this mode.
  8. Right-click Onboarding Modeling Project, and select Analyze Model Implementation Changes...
  9. A window opens for the change analysis. Click Browse... then select the change file you exported in step 6, and click Open. You can then click Next to move to the next panel.
  10. Select the elements you want to analyze. Click Select all, then Finish.
  11. A new Change Analysis View tab opens in Modeler (Figure 5). Expand out all of the folders to see all of the changes.
    Figure 5. Change analysis view
    Figure 5. Change analysis view
  12. Examine the change list. Not every change to the technical model is reflected in the change list because the business model does not represent every possible attribute in the technical model. For example, the business model does not have an attribute that maps to the control over transactionality. This type of change does not flow back into the business model. The change to the task order did flow back however.
  13. You can apply or ignore any of the changes. Click on one of the changes to see the details, as shown in Figure 6.
    Figure 6. Change details
    Figure 6. Change details
  14. Currently, these changes must be made manually. Follow through the change list, making the appropriate updates in the business model. As you make each change, you can click it and select Change Applied to indicate you completed it, or Change Ignored to indicate that you found the change not to be business relevant.

After the changes have been made, the process should look like Figure 7, with the Assign Office Space human task now preceding Add To Payroll System.

Figure 7. Updated process in Modeler
Figure 7. Updated process in Modeler

Limitations

The fact that changes to technical attributes are not reflected in the business model should not be viewed as a limitation. Since those attributes are not part of the business model, there is nothing to be changed. The same goes for the updates to the Java components. Modeler only knows that a task is to be exported as a Java component. There is nothing in Modeler to reflect the actual Java code to be used. These changes are not business relevant to the business model.

However, the updates to the business rule was something that could have been brought back into the business model, but was not reflected in the change list. This limitation has been eliminated in Version 6.1.2.

Another limitation is that not every construct in WebSphere Integration Developer has an equivalent in Modeler. For example, if you updated the process to use a cyclic flow construct, there is no way to propagate that change back to Modeler.

Late update

In the late update scenario, the business analyst makes a change to the business model after it has been exported to WebSphere Integration Developer. For this example, suppose the analyst notices a new data field is needed for the Schedule Training task. In addition, the analyst realizes that a janitor could get a parking space with the current procedure. The process should only flow down the Yes path if the location business rule evaluated to true, and the job code is not equal to "J01."

Update the business model

To support the required updates, open Modeler to the workspace with the Onboarding Modeling Project.

  1. Expand the Business Items folder, and double click New Hire Information so you can edit it.
  2. Click Add so that a new attribute is added to the bottom of the list.
  3. Click on the default name Attribute to select it, then type in Schedule Date.
  4. Click on the type Text for Schedule Date. A button will appear to the right of the field. Click the button to select the type. Select the basic type Date, then click OK. If you see a warning to confirm the operation, click OK.
  5. Save and close New Hire Information.

Next, the decision logic needs to be updated. Before performing this step, ensure that you are in Intermediate Mode or higher. You cannot set decision logic in Basic Mode.

  1. Select the decision Assign Parking Space? and click on the Attributes tab.
  2. Click on the Output branches sub-tab, then click Yes to select the top output. Scroll to the bottom of the attributes, and you will see the current expression used in the decision:

    'Processes.Onboarding - ToBe.Assign Parking
    Space?.Input:2.Parking' is equal to "Yes"

  3. Click Edit... to change the expression. The expression editor opens.
  4. Click Add to add another expression. The default is to perform a logical "and" operation on the two expressions, which is what is needed for this case.
  5. For the first term, select Modeling artifact. In the list below, select Job Code.
  6. For the operator, select is not equal to.
  7. For the second term, select Text, then replace the text value with J01. The expression should now look like the one in Figure 8.
    Figure 8. Expression editor
    Figure 8. Expression editor
  8. Click Apply to update the expression with these values. (If you don’t click Apply, your work will be lost!)
  9. Click OK to close the expression editor.

The expression should now be:

Listing 2. Edited expression
( 'Processes.Onboarding - ToBe.Assign Parking 
Space?.Input:2.Parking' is equal to "Yes" )
AND ( 'Processes.Onboarding - ToBe.Assign Parking 
Space?.Input:2.Job Code' is not equal to "J01" )

With these two updates, the business process is now up to date. It is time now to export it out to WebSphere Integration Developer.

  1. Right-click Onboarding - ToBe and select Export...
  2. For the type select WebSphere Integration Developer, and click Next.
  3. Confirm the director for exporting, and that Onboarding - ToBe has been selected, then click Next.
  4. Keep the default value Recommended Export Option as you did before. This time, change the Project Interchange Name so you will know this is the updated version of the process model. Change the name to Onboarding Update, then click Finish.
  5. When you see the message "Export finished successfully," click OK.

If your system does not have the capacity to run both at the same time, you can now exit Modeler and start WebSphere Integration Developer.

  1. In WebSphere Integration Developer, right-click OnboardingModelingProject, and select Synchronize with Modeler Export...
  2. For the PI .zip file, click Browse... and navigate to the directory where you previously exported from Modeler. Select the Onboarding Update file, and click Open. You can then click Next to verify that the projects in the project interchange file and the workspace match up.
  3. Click Synchronize. If you receive a pop-up message about the synchronize dialog, click OK to clear it.
  4. In the list of affected artifacts, click on NewHireInformation. You will see that the ScheduleDate field was added. Right-click The field "ScheduleDate[xsd:date]" was added, and select Apply to accept this change.
  5. Click on the Onboarding process. You will see several changes relating to having repositioned the task. Although this change originated in WebSphere Integration Developer, you still updated the business model, causing the change to show up in the list. Right-click on each of these, and select Apply.
  6. The Valid from date of the process is changed, since it is set to the date and time when the export from Modeler is performed. This date is used to version the process at run time. If you would like to keep the version the same, right-click this change and select Reject. If you don’t mind a different date for versioning, you can accept this change.
  7. The update to the decision shows in the lines that read:

    body property on Condition was changed...

    Right-click each of these and select Apply.

  8. One change is for the transactional behavior. Importing the version from Modeler could overwrite the updates you made in WebSphere Integration Developer.
  9. One change is related to the extra template instance for the business rule. You would want to reject this change, since it was something you added in. However, the option to reject is grayed out. Simply skip this change.
  10. There are also several changes relating to imports. All of these can be accepted, but the option to reject is grayed out. These relate to the imports changing due to the different data type. You can accept each of these.
  11. Click Commit to commit the changes.

The changes from Modeler flow automatically into WebSphere Integration Developer.

  1. Edit the NewHireInformation business object in OnboardingModelingProject_lib. The ScheduleDate field is now included, as shown in Figure 9.
    Figure 9. Updated business object
    Figure 9. Updated business object
  2. Edit the Onboarding process. Select Schedule Training, click the Attributes tab, then the Server sub-tab. The radio button for Participates is still selected.
  3. Click on the link from Apply Location Rules to Assign Parking Space. In the Attributes tab, click on Details. The logic includes the expression for the Job Code.

The late changes to the business model have flowed into the technical model. The ability to accept or reject each update enables the integration developer to bring in changes, but to also keep the updates they might have made after importing the model from Modeler the first time.

Limitations

In the flow from Modeler to WebSphere Integration Developer, the only limitation found in this example was that some of the changes could not be rejected, only accepted. The integration developer has to understand each of the changes, and their impact if they were to accept or reject them.

Round-trip update

Round-tripping for modeling tools has been a long sought-after goal. In a round-trip scenario, the business model has been completed, the technical model is also completed, and placed into production. Based on process improvements or new requirements, the business model needs to evolve, which drives changes to the technical model.

In other words, this is really just a special case of the late update scenario demonstrated above. The difference is that a copy should be maintained for the original version, so that development has a copy of what is being used in production. There are two basic methods you could use to keep different copies of the same project:

  • Use a version control system such as IBM Rational® ClearCase®. The workspace for the completed project could be stored in ClearCase as version 1. When updates from the business model are brought into the project, the project could be stored as version 2. This would enable a developer to pull out either version to work on it.
  • Copy the original modules in the workspace and refactor them to new names to reflect that they are the original version. You could then merge in the changes from the business model, and continue with the development cycle.

Limitations

All of the limitations noted for the technical update and late update scenarios apply to the round-trip scenario.

Conclusion

This article discussed development cycles with Modeler and WebSphere Integration Developer. Scenarios where models get updated were explored and demonstrated, showing how changes to the model in WebSphere Integration Developer can be brought back into the business model, and how changes in Modeler can be brought into WebSphere Integration Developer, without having to overwrite any updates that might have been previously made.


Download

DescriptionNameSize
Sample codeOnboardingModelingProject.zip295 KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=355774
ArticleTitle=Iterative development in WebSphere Business Modeler and WebSphere Integration Developer
publish-date=12042008