Solution implementation guide

IBM(R) WebSphere(R) Business Integration Collaborations for Telecommunications provides an end-to-end view for implementing business integration projects using the artifacts included in the WebSphere Business Integration Collaborations for Telecommunications industry solution library. This document describes the development process and methodology that you should use to implement a WebSphere Business Integration Collaborations for Telecommunications solution.

Development process

Implementing a WebSphere Business Integration Collaborations for Telecommunications solution encompasses the following development phases:

These development phases are described in the following sections.

Requirement analysis

The first step in analyzing requirements is to identify business problems that need to be solved. A problem may be identified within existing operations, or within an area where the organization intends to expand its operations. By identifying problems, you provide a clear objective for subsequent work intended to resolve the problem. You also have a basis for assessing the relative merits of various proposed solutions.

The second step in analyzing requirements is to frame solutions for problems in a way that both management and users can understand. To do this, you must create a logical model  that describes all of the parts that make up the solution, the purpose, function and interconnections of the parts, and the range of actions that users will be able to perform with each part.

Your logical model should also define the scope of the solution. The scope of a WebSphere Business Integration Collaborations for Telecommunications solution can encompass either business process integration, or application integration.

An integration project with business process integration scope can either use the complete set of WebSphere Business Integration Collaborations for Telecommunications business process templates, or it can integrate a subset of the business process templates with existing processes.

An integration project with application integration scope utilizes collaboration templates.

System design

Once you have defined the requirements and the logical model for a solution, you can begin to define a system design. In this phase of the development process, you apply real-world technical constraints to the logical model, including implementation and performance considerations. System design definition addresses the following questions:

A business process choreography represents the dynamic behavior of business activities based on how a business is run.

Examination of industry solution library artifacts

WebSphere Business Integration Collaborations for Telecommunications contains an industry solution library with artifacts that support business process choreographies for a variety of  business process use cases. Each of these use cases is based on the eTOM business process framework defined by the TeleManagement Forum. In this phase of development, you examine the artifacts contained in the industry solution library in order to determine their suitability for your integration project, based on the system design that you defined in the previous phase.

The following sections describe the procedure for assessing each type of artifact.

Overview and use cases

Detailed descriptions of each collaboration are provided in the overview and use case documents. The domain analyst uses the overview and use case to determine whether the WebSphere Business Integration Collaborations for Telecommunications business processes are sufficient to meet requirements defined by the organization.

WebSphere Business Integration Collaborations for Telecommunications provides overview and use case documents for the following collaborations:

Business process templates

If the overview and use case indicates that a collaboration is sufficient to meet requirements, the next step is to examine the business process in greater detail to determine whether any customization is required.

For each use case except Service Usage, a business process template provides an implementation of the business process choreography that can be run as a WebSphere MQ Workflow process. WebSphere Business Integration Collaborations for Telecommunications provides you the flexibility to re-sequence the process nodes in a workflow template, using WebSphere MQ Workflow Buildtime tools.

WebSphere Business Integration Collaborations for Telecommunications provides the following documents for business process templates:

These business process templates describe the activities contained in each business process, as well as the business objects, data structures, and collaboration templates that the process uses. 

Collaboration templates

The WebSphere Business Integration Collaborations for Telecommunications industry solution library provides a set of a IBM WebSphere Business Integration Collaboration templates targeted specifically to telecommunications processes. These collaboration templates are integrators at the application and data level, unlike the collaborations described earlier.

Just as you examined each business process template to determine its sufficiency to meet your requirements, you should do the same for each collaboration template you will use in your integration project. Each business process template uses one or more collaboration templates. If no collaboration template meets your defined needs, you must develop a new collaboration template.

WebSphere Business Integration Collaborations for Telecommunications provides the following documents for the collaboration templates included in the industry solution library:

Generic business object templates

You should also examine the generic business objects used in the business process, in order to assess their sufficiency to meet your requirements. If existing generic business objects do not meet your defined needs, you must develop new generic business object templates.

WebSphere Business Integration Collaborations for Telecommunications provides the following documents for the top level generic business object templates included in the industry solution library. These documents provide links to child generic business objects:

For a graphical view of the relationships between these top-level generic business objects, see Generic business objects.

Installation

Before you can customize the WebSphere Business Integration Collaborations for Telecommunications templates, you need to install WebSphere MQ Workflow Buildtime and IBM WebSphere InterChange Server. Optionally, you may install IBM WebSphere Business Integration Modeler (formally called Holosofx BPM Workbench) for the Fault Resolution scenario. To install these products, refer to the installation guide for each of product.

The artifacts included in the WebSphere Business Integration Collaborations for Telecommunications industry solution library have the formats indicated below. In order to customize these artifacts for a specific integration project, you must import the artifacts into the development environment.

All TXT files can be imported using the  "repos_copy" command. All WebSphere MQ Workflow FDL files can be imported to WebSphere MQ Workflow Buildtime using the WebSphere MQ Workflow user interface. The IBM WebSphere Business Integration Modeler organization file can be imported to IBM WebSphere Business Integration Modeler using the its user interface.

For complete installation instructions, see the WebSphere Business Integration Collaborations for Telecommunications Installation Guide.

Design and implementation

This phase of development encompasses more fine-grained design and implementation work than the previous phases, addressing issues such as how to handle exceptions and how to call other processes. Another significant part of this phase of development is customizing templates from the WebSphere Business Integration Collaborations for Telecommunications industry solution library.

Information on how to address specific design and implementation issues, including error handling is provided in the Solution integration section of this document.

Customize templates

The WebSphere Business Integration Collaborations for Telecommunications solution provides several integration patterns for IT programmers or administrators to customize artifacts for specific integration projects.

The diagram below shows an overview of integration means between WebSphere MQ Workflow and IBM WebSphere InterChange Server. The following sections also provide detailed information about how to use, customize, and deploy these patterns.

System assumptions

WebSphere Business Integration Collaborations for Telecommunications business process models are described as workflow templates. Workflows are defined in Flow Definition Language (FDL). In most situations, these templates need to be modified periodically in order to reflect your changing business strategy. Using WebSphere MQ Workflow Buildtime, you can easily modify these templates to meet your requirements. You can then import the modified templates directly to the WebSphere MQ Workflow server. Refer to Business Process Modeling with WebSphere MQ Workflow
(http://www-4.ibm.com/software/ts/mqseries/txppacs/wd01.html) for detailed information about developing business processes using WebSphere MQ Workflow. This document gives a step by step overview of how to implement simple processes using WebSphere MQ Workflow and also covers more advanced process models. It is intended for business analysts and process modelers with a basic knowledge about WebSphere MQ Workflow.

Collaboration templates connect with applications in order to provide aggregate functions to business processes. Collaboration templates are not designed for customization; however a collaboration template provides a lot of flexibility at deployment time. For example you can use a collaboration template to create a collaboration object that connects to one set of applications, and then use the same template to create another collaboration object that connects to a different set of applications. If no collaboration template meets your requirements, you can develop a new collaboration template that extends an existing one. Refer to the System Implementation Guide for more information on developing collaboration templates.

WebSphere Business Integration Collaborations for Telecommunications also provides many useful generic business objects for the telecommunications industry. You can use these generic business objects to work with new collaboration templates that you develop for integrating applications. If your existing application has elements that are not covered by the generic business object, you can customize the appropriate generic business object template according to your needs. To create generic business objects, you can use the Business Object Designer. Refer to the System Implementation Guide for more information on developing generic business object templates.

Develop application-specific business objects and maps

When connecting to applications for a business integration project, you normally need to design and implement a set of application-specific business objects (ASBOs) and maps for the connected applications. Refer to the System Implementation Guide for information on using IBM WebSphere InterChange Server tools to design and implement application-specific business objects and maps.

Testing and problem detection

Testing and problem detection are important processes for an integration project. WebSphere MQ Workflow and IBM WebSphere InterChange Server each execute testing and problem detection. Business process templates are executed by WebSphere MQ Workflow server, and collaboration templates and generic business objects are executed by IBM WebSphere InterChange Server.

The following sections describe procedures you can use to test and detect problems.

Test business process templates

WebSphere Business Integration Collaborations for Telecommunications business process templates are delivered as WebSphere MQ Workflow templates. To test these templates you need to execute them in WebSphere MQ Workflow Server. Two types of test can be executed in WebSphere MQ Workflow: unit testing or quick prototyping, and development verification testing.

Unit testing or quick prototyping

To execute unit tests you can use the fmcnshow.exe program provided by WebSphere MQ Workflow. This program is located in the bin sub-directory under WebSphere MQ Workflow installation directory. This program provides features that read the fnput containers of a Workflow Server, display the containers' current value, and allow you to change and to set the output containers.

Development verification testing

You can use the Java Generic API test and prototyping Tool (JGATT) to execute development verification tests. JGATT is available in SupportPac WA04.

JGATT components offer the features required to perform tests of WebSphere MQ Workflow API definitions independent of the platform on which they are to be implemented. They also allow you to perform other tasks, including the following functions:

To perform test cases with JGATT, you create a file (such as <testcase>.dat) that uses Java/C API Tool Syntax, invoke the tool and check the execution result in a log file (such as <testcase>.log).

Refer to WA04: WebSphere MQ Workflow - Java Generic API test and prototyping tool for more detailed information on development verification testing.

Test collaboration templates

To test collaboration templates you need to run them on the IBM WebSphere InterChange Server system. IBM WebSphere InterChange Server provides various tools for testing. For more information, see the System Implementation Guide.

Deployment

All software artifacts of the WebSphere Business Integration Collaborations for Telecommunications industry solution library can be exported from build-time or designer environments. Upon completion of the customization and development phase, you will have produced the following artifacts:

All TXT files can be imported using the "repos_copy" command. All WebSphere MQ Workflow FDL files can be imported to WebSphere MQ Workflow Runtime using a command line interface with a command such as the following:

   fmcibie /i=<filename>.fdl

Solution integration

The following sections provide detailed information for the issues you may encounter when integrating a telecommunications solution.

Exception handling

WebSphere Business Integration Collaborations for Telecommunications uses WebSphere MQ Workflow to manage business processes, and it also uses WebSphere MQ Workflow to provide exception handling. The capabilities of WebSphere MQ Workflow for accommodating exceptions in Workflow systems are essential to WebSphere Business Integration Collaborations for Telecommunications integration projects. WebSphere Business Integration Collaborations for Telecommunications eliminates problematic branches from process templates and assumes that all customizations of process templates apply a case-by-case policy for exception handling. This section provides general concepts for error handling and practical examples of how to apply error handling to a workflow process template.

From an action point of view, different strategies for resolution are possible during exception handling, including managing errors by administrative actions, or modifying and evolving workflow graphs.

Managing errors by administrative actions

Errors can occur when a process is executed. For example, an activity implementation may return incorrect data in the output container, the implementation of an activity may not be found, or a user may attempt to perform an unauthorized activity.

The workflow management system uses a set of default actions to cope with these situations, such setting the activity status to "inError" and informing the appropriate role such as an administrator so that corrective actions can be taken. In this example, the administrator may use the WebSphere MQ Workflow client console to issue a "force restart" command to repeat the current task, or a "force finish" command to skip the current task.

In order for a person in the management role to effectively manage errors, he or she much have a thorough understanding of the semantics of the process.

Modifying and evolving workflow graphs

A conversational approach to exception handling often requires manual work. A more radical approach is to make one or more changes to a flow at run-time. This approach aims at avoiding exceptions or subsequent automatic exception handling. Many policies may be applied to resolve exceptions, including the following policies:

The following section describes "re-execution" and "forward recovery" resolution patterns as samples.

Re-execution

Manual tasks by humans are inherently error-prone even when the system performs syntax or data validation checks. A series of a manual and application activities that relies on human inputs may need to be re-executed if the input does not meet constraints or requirements specified by the application.

Re-execution can be implemented by extracting this pattern from the graph (shown in the first diagram below) and by replacing it with by a sub-flow that contains the original extracted sequence and a continuous branch decision activity (shown in the second diagram).

Original sequence

Sub-flow

Forward recovery

A collection of activities may contain activities with transactional implementations and activities with non-transactional implementations. If one of the activities within this group is performed incorrectly and therefore must be repaired, then all the other pieces of work that have already been performed must be repaired too. A unit of work of this type can be added into the workflow graph as showed in the diagram below. The forward recovery consists of resetting the values to their original states. If this "undo" task can be executed automatically, it can be implemented by a collaboration object that spreads whole recovery sub-tasks among related applications.

Forward recovery

User interactions

User interactions allow human participants to interact with the business process management system. The WebSphere Business Integration Collaborations for Telecommunications solution supports human interactions, but does not provide Web client implementations in the industry solution library. This section describes two typical implementations of user interactions with the WebSphere MQ Workflow. The first interaction is a simple case, and the second is a navigation sequence through multiple screens.

Simple case

In this example, the user accesses a WebSphere MQ Workflow process via a Web client. The Web client is a Java servlet that provides a Web interface. The Web client allows you to perform several tasks, such as creating worklists, starting and stopping process instances, starting and stopping activities, and monitoring processes. This feature only exists in WebSphere MQ Workflow V3.3 and subsequent release levels. This example is shown in the following diagram.

User interaction: simple case

Common utilizations of this simple type of user interaction in the WebSphere Business Integration Collaborations for Telecommunications scenarios include starting a process instance, and checking out and checking in work items in order to perform manual activities.

When a client invokes a checkout and the process is successful, the Web client automatically sends a Java Server Page (JSP) to the Web browser. The sent JSP contains a form with the input container data. When this form is submitted, the Web client's servlet maps the form fields to output container elements, and then checks in the work item. During this series of interactions, the Web client maintains the communication session between the browser and the WebSphere MQ Workflow process.

If the default GUI supplied by the JSP matches your requirements, implementation of the user interaction requires little effort to install and configure. You can also customize a JSP layout. Refer to the product documentation of WebSphere MQ Workflow for more detailed information.

In the WebSphere Business Integration Collaborations for Telecommunications solution, the Web client is the default implementation for some interactive activities, such as customer data validation by a customer service representative (CSR), or data collection and entry by the CSR.

The SupportPac WA83: Rapid Deployment Wizard
(http://www-4.ibm.com/software/ts/mqseries/txppacs/wa83.html) is a tool that you can use to quickly and easily design JSP files for the WebSphere MQ Workflow Web client.

Navigation sequence through multiple screens

The WebSphere MQ Workflow Web client supports a single JSP for single manual activities. If you want to develop a series of JSP screen navigations that correspond to a single interactive business process activity, SupportPac WA84 supports these requirements.

WebSphere MQ Workflow SupportPac WA84 - Web client Extensions V1.0 provides a set of components for developing applications based on WebSphere MQ Workflow Web client. Using these functions, you can develop Workflow applications with professional, attractive, and sophisticated Web-based user interfaces. The extended components are fully compatible with other functions provided by the Web client.

The extension allows a workflow process activity to navigate through multiple JSPs and return to the activity. For detailed information, refer to http://www-4.ibm.com/software/ts/mqseries/txppacs/wa84.html.

The extension includes a user exit framework that provides the capability to plug in to a user application when transferring between one JSP and another JSP. Instead of calling a workflow process, you can call a collaboration object at the user exit. For example, you may want to use a collaboration object based on the ReturnTelcoProducts collaboration template (provided in the WebSphere Business Integration Collaborations for Telecommunications solution industry library) to retrieve a list of data from an application. How to call a collaboration object is described in the Server Access Interface Development Guide.

Configuration for IBM WebSphere Business Integration Adapter for MQ workflow

In the WebSphere Business Integration Collaborations for Telecommunications solution, collaboration objects are used to support business process activities. In terms of WebSphere MQ Workflow, a collaboration object flow can be a program activity in a workflow process. You can invoke collaboration objects from within a process using IBM WebSphere Business Integration Adapter for MQ Workflow.

You can configure a WebSphere MQ Workflow activity to issue requests to external functions via a User-defined Program Execution Server (UPES). In order to use the IBM WebSphere Business Integration Adapter for MQ Workflow as a UPES, you need to set the execution unit parameter of the program activity node within the workflow process. You can specify this parameter on the Execution tab of the properties dialog for the program activity node. In the Program execution server area, select the Server button and then enter the appropriate UPES name manager name of the IBM WebSphere Business Integration Adapter for MQWorkflow. This UPES name should be defined previously in the network view.

UPES Setting

The program definition corresponding to this activity node must have a parameter in the form: verb="verb_name" as shown in the diagram below. You do not need to specify a collaboration object name.

Verb setting

For more detailed information about the configuration, please refer to the Adapter for WebSphere MQ Workflow User Guide.

WebSphere MQ Workflow Adapter

The IBM WebSphere Business Integration Adapter for WebSphere MQ Workflow links IBM WebSphere Business Integration Collaborations and WebSphere MQ Workflow processes. This section contains information specifically for using the Adapter for WebSphere MQ Workflow with the WebSphere Business Integration Collaborations for Telecommunications solution. For complete information on the adapter, refer to the Adapter for WebSphere MQ Workflow User Guide.

The WebSphere Business Integration Collaborations for Telecommunications use cases assume the following patterns of communication:

Integration patterns between MQSeries Workflow and IBM CrossWorlds Interchange Server

Application Specific Business Objects (ASBOs)

The container business object has the following structures.

Activity Implementation Request

Business object level application specific information:

  cw_mo_wfcontainer=ContainerInfo
  cw_mo_wfactivityrequest=ActivityRequestMO
Activity Implementation Request
Element Name Element Type Description
Input_name Generated by FDLBOGen This business object corresponds to WebSphere MQ Workflow input container.
ContainerInfo MO_WebSphere MQ Workflow_
ContainerInfo
This Meta-Object is for reference use only. See the Adapter for WebSphere MQ Workflow User Guide for more detailed information.
ActivityRequestMO MO_WebSphere MQ Workflow_
ActivityRequest
This Meta-Object represents correlation information between request and response. The element ExternalProcessContext is exposed for the purpose of being tracked from a tracking system outside of WebSphere MQ Workflow. The details of this Meta-Object are provided in the following table
ObjectEventId String  
MO_WebSphere MQ Workflow_ActivityRequest
Element Name Element Type
ActImplCorrelID String
Starter String
ProcTempID String
ProgramName String
ResponseRequired String
ExternalProcessContext String
ObjectEventID String

Activity Implementation Response

Business object level application-specific information:

  cw_mo_wfactivityresponse=ActivityResponseMO
Activity Implementation Response
Element Name Element Type Description
ActivityResponseMO MO_WebSphere MQ Workflow_
ActivityResponse
This Meta-Object contains correlation information between request and response. The details of this Meta-Object are provided in the following table.
Output_name Generated by FDLBOGen This business object corresponds to the WebSphere MQ Workflow output container.
ObjectEventId String  

MO_WebSphere MQ Workflow_ActivityResponse
Element Name Element Type
ActImplCorrelID String
Starter String
ReturnCode String
ObjectEventId String

Process Invocation

The top level application-specific business object used in this example contains the invocation request structure and the response structure.

Business object level application specific information:

  cw_mo_wfptcfg=MO_Config; cw_mo_wfpid=ProcessInstance
Process Invocation
Element Name Element Type Description
Input_name Generated by FDLBOGen This business object corresponds to the WebSphere MQ Workflow input container of the process instance.
MO_Config MO_WebSphere MQ Workflow_
ProcessTemplateConfig
This structure represents the workflow process template you want to invoke. It is used for an invocation request. The details of this Meta-Object are provided in the following table.
ProcessInstance MO_WebSphere MQ Workflow_
ProcessInstance
This structure represents the workflow process instance you invoked. It is used for a return message from Workflow server as a process invocation result. The details of this Meta-Object are provided in the second table following this table.
ObjectEventId String  

MO_WebSphere MQ Workflow_ProcessTemplateConfig
Element Name Element Type Description
ProcessTemplateName String  
ProcessInstanceName String  
KeepName String  
UserId String  
ExecutionMode String For ProcessTemplateCreateAnd
StartInstance execution, specify asynchronous.
For ProcessTemplateExecute execution, specify synchronous.
ResponseTimeout String If the value is set to a negative number, no returns are allowed
TimeoutFatal String  
ExternalProcessContext String  
ObjectEventId String  

MO_WebSphere MQ Workflow_ProcessInstance
Element Name Element Type
ProcInstID String
ProcInstName String
ProcInstParentName String
ProcInstTopLevelName String
ProcInstDescription String
ProcInstState String
LastStateChangeTime String
LastModificationTime String
ProcTempID String
ProcTempName String
Icon String
Category String
ExternalProcessContext String
ObjectEventId String

Usages of the connector

The connector enables a collaboration object to monitor and control the status of a WebSphere MQ Workflow process using MO_WebSphere MQ Workflow_ProcessInstance object described above. To do this, the connector uses the Java API between the connector and WebSphere MQ Workflow server.

Process Invocation, Activity Implementation Request, and Activity Implementation Response utilize the XML API to communicate with the Workflow server. The verb of the application-specific business object sent from a collaboration object to the Workflow is ignored by the connector.

The connector also supports the use of the Java API with the following verbs for ProcessInstance business object.

In the current release the WebSphere Business Integration Collaborations for Telecommunications solution does not provide any collaborations that implement these usages. However, you can implement these usages with the ProcessInstance business object. For more information, see the Adapter for WebSphere MQ workflow.

XML API Verb Processing

The above mentioned three patterns utilize XML API to communicate with a Workflow server. The connector processes the verb between WfMessage and application-specific business object as follows:

The mapping between the verb in a WebSphere MQ Workflow application-specific business object and a generic business object is specified by a Map component.

Invoking a workflow process from a collaboration object

The following sequence describes how a business event triggers a workflow process:

  1. An application connector is monitoring an application event
  2. An event is transferred to the InterChange Server through the application connector
  3. A collaboration object that subscribes to this type of events calls the MQ Workflow connector
  4. The connector starts an appropriate workflow process instance
  5. Once the process instance starts successfully, the WebSphere MQ Workflow connector agent returns success

MQSeries Workflow asynchronous process invocation

You can configure a collaboration object so that the collaboration object submits a workflow invocation and waits until completion. Before setting up this type of implementation, you must ensure that the workflow process can return the response immediately.

MQSeries Workflow synchronous process invocation

Calling a synchronous business function

The following sequence describes the details of workflow calling a synchronous business function:

  1. A process instance posts an ActivityImplInvoke message into a defined UPES (User Program Execution Server) queue for WebSphere MQ Workflow connector.
  2. The WebSphere MQ Workflow connector that is monitoring the UPES queue receives the message.
  3. The WebSphere MQ Workflow connector converts the message to an application-specific business object, and then sends it to the IBM WebSphere InterChange Server.
  4. A collaboration object that subscribes to this type of events executes the defined process, and then calls the WebSphere MQ Workflow connector using another port with a return application-specific business object.
  5. The WebSphere MQ Workflow connector converts the return application-specific business object to an ActivityImplInvokeResponse message.
  6. The WebSphere MQ Workflow connector posts a message to the response queue to complete the activity.
  7. Once the WebSphere MQ Workflow connector posts a message successfully, it returns success.

Synchronous program activity

Calling an asynchronous business function

The asynchronous business function call is similar to the synchronous business function call as described in the previous section. Since the activity expects a long running process, the collaboration object that checks out request data and the collaboration object that checks in return data are different collaboration objects.

  1. A process instance posts an ActivityImplInvoke message into a defined UPES (User Program Execution Server) queue for WebSphere MQ Workflow connector.
  2. The WebSphere MQ Workflow connector that monitors the UPES queue gets a message from the UPES queue.
  3. The WebSphere MQ Workflow connector converts the message to an application-specific business object, and then sends it to the IBM WebSphere InterChange Server.
  4. A collaboration object that subscribes this type of events navigates through the defined process and then calls the application connector that handles a long running activity asynchronously.
  5. Once long running function processing completed, the appropriate connector detects the completion event and sends the response back to the IBM WebSphere InterChange Server as new event.
  6. The response collaboration object that subscribes to the completion event sends it to the WebSphere MQ Workflow connector.
  7. The WebSphere MQ Workflow connector converts the return application-specific business object to an ActivityImplInvokeResponse message.
  8. The WebSphere MQ Workflow connector posts a message to the response queue to complete the activity.
  9. Once the WebSphere MQ Workflow connector posts a message successfully, it returns success.

Asynchronous long running activity

Correlation resolution

When multiple applications work together collaboratively, process context propagation and resolution are generally required in order to support applications that typically run in multi-threaded environments. This section provides general concepts for this kind of integration pattern.

The following diagram shows how the activity correlation id resolves relations between activity implementation request and response flows in the synchronous activities. All collaboration templates provided by WebSphere Business Integration Collaborations for Telecommunications keep and return a unique correlation id.

Correlation resolution in a synchronous activity

The next diagram shows an example of an asynchronous activity. This example assumes that a connector manages the relation between request and response for long running processes. This model depends on application and the corresponding connector to hold the correlation id.

Correlation resolution in an asynchronous activity

The next diagram shows a flexible example of asynchronous activity. In this example, IBM WebSphere InterChange Server resolves the relationship of each id in the global process context for a collaboration object. To implement this pattern, you need to develop a  map and a relationship. For more detailed information about developing maps and relationships, see the Map Development Guide.

In addition to the above mentioned map and relationship, the WebSphere MQ Workflow Asynchronous Response must set the value of ActImplCorrelID in the ActivityResponseMO.

 Correlation resolution with relationships and maps

User Authentication

For the WebSphere Business Integration Collaborations for Telecommunications solution, the following three security domains must be considered for security configuration:

IBM WebSphere InterChange Server

The WebSphere MQ Workflow connector uses CORBA/IIOP to communicate with IBM WebSphere InterChange Server. In the current release IBM WebSphere InterChange Server does not have a configuration point for CORBA/IIOP communication.

MQ Queue Manager

The MQ Queue Manager security domain delegates user authentication functions to the operating system (Windows NT or AIX, for example). In other words, you need to register user ids in the operating system if order for a user to use MQ queues. For this reason, if the security is turned on, each queue message needs to pass the user id, password or credentials in order to use the queue. The WebSphere Business Integration Adapter for MQ Workflow uses MQ queues for its request and response communication mechanism, and therefore needs to pass the user id and password or credential in its message header.

WebSphere MQ Workflow

WebSphere MQ Workflow has its own authentication mechanism, using a role-based system. Each user has to register in the user registry, in order to gain access. If the security is turned on, any program activities performed by a User-defined Program Execution Server (UPES) should be authenticated. In other words, WebSphere MQ Workflow client has the authentication capability.

When you want collaboration objects to control WebSphere MQ Workflow process instances, there are two possible ways to accomplish this. One way is by invoking the workflow Java APIs for suspend, resume, delete, and retrieve operations. For the start operation you need to use the XML API.

The WebSphere MQ Workflow connector has user id and a password properties that can be used for Java API authentication. These properties are used only for suspend, resume, delete, and retrieve operations, and this is the only way to configure security for Java API. You cannot change the security subject and credentials dynamically.

To start a process instance, the WebSphere MQ Workflow connector uses the WebSphere MQ Workflow XML command API. The XML message must contain a registered WebSphere MQ Workflow user name. The collaboration object that invokes a process must set the concrete value to MO_WebSphere MQ Workflow_ProcessTempleteConfig.userid.

IBM WebSphere Business Integration collaboration development

The following sections provide information that applies specifically to collaboration object development within the context of the WebSphere Business Integration Collaborations for Telecommunications solution. For complete information about developing collaboration objects, see the Collaboration Development Guide.

WebSphere Business Integration Collaborations for Telecommunications collaboration templates

The WebSphere Business Integration Collaborations for Telecommunications architecture applies the following four patterns of communication patterns between WebSphere MQ Workflow server and IBM WebSphere InterChange Server:

Invoking a workflow process

This type of collaboration template has only a Main scenario at the top level. In the flow, a workflow process is invoked in the Send Verb sub-scenario. The following diagram shows an example of the logical flow for a Main scenario.

Logical flow that invokes a workflow process

Implementing a synchronous activity

This type of collaboration template has Main and Retrieve top-level scenarios. If the verb of the triggering business object is retrieve, the Retrieve scenario is called. The Main scenario is called for the other verbs, such as create, delete and update.

This type of collaboration template is designed to support synchronous communication with the WebSphere MQ Workflow server. If an invoked activity needs to return an output business object, the Main and Retrieve scenarios both provide a Return process.

The following diagram shows the logical flow of a Main scenario of this type.

Synchronous activity Main scenario logical flow

The following diagram shows the logical flow of the Retrieve scenario.

Synchronous activity Retrieve scenario logical flow

Implementing an asynchronous activity

This type of collaboration template has Setup and ReturnSetupResult top-level scenarios. Collaboration templates of this type are used for bi-directional asynchronous communication. Two collaboration objects are typically created from the same template. The first collaboration object issues the request from WebSphere MQ Workflow, and the other receives for the response for WebSphere MQ Workflow. The Setup scenario is used in the request collaboration object, and the ReturnSetupResult scenario is used in the response collaboration object.

The following diagram shows the logical flow of the Setup process.

Asynchronous activity Setup scenario logical flow

The following diagram shows the logical flow of the ReturnSetupResult process.

Asynchronous activity ReturnSetupResult scenario logical flow

Retrieving a List pattern

This type of collaboration template has only a Retrieve top-level scenario. This type of collaboration template supports user interaction business activities. The Retrieve scenario has the same logical process flow as the Retrieve scenario in the synchronous activity implementation. The following diagram shows this logical flow.

Retrieving a List activity Retrieve scenario logical flow

SYNC_FROM_SOURCE

If a business object has another business object as a key reference, the parent business object sometimes requires the whole contents of the reference business object. WebSphere Business Integration Collaborations for Telecommunications collaboration templates provide a scenario that supports this case. All collaboration templates have the SYNC_FROM_SOURCE sub-scenario, except those collaboration templates that have the "Retrieving a list" pattern.

The following diagram shows the logical flow of the SYNC_FROM_SOURCE process. This flow is invoked if value of the SYNC_FROM_SOURCE property of the collaboration object is set to "true".

SYNC_FROM_SOURCE logical process flow

Developing collaboration objects

Collaboration objects are usually utilized in order to achieve data synchronization. Developers should be careful to maintain data consistency among collaboration objects. If multiple collaboration objects that subscribe to the same business object each have transactional behavior, developers should use a transactional graph outside of the InterChange Server to manage the data consistency and data state transition, and to avoid creating processing loops. These requirements can be very very complicated and difficult to meet.

The WebSphere Business Integration Collaborations for Telecommunications architecture follows the policy that only one manager collaboration object can manage a particular entity. This policy is called entity management model.

The pattern for asynchronous processing utilizes collaboration objects in a message-passing model. This model is different from the entity management model, because it assumes that multiple collaboration objects can be used. Normally at least two collaboration objects are required in the asynchronous pattern.

The following sections summarize general deployment information for each communication pattern used by collaboration templates.

Invoking a workflow process

When a collaboration object communicates by invoking a workflow process, the SourceApp port can be connected to the entity source application connector or port connector. The To port can be connected to WebSphere MQ Workflow. This type of collaboration object is configurable using the SYNC_FROM_SOURCE parameter. If the value of this parameter is set to "true" then the collaboration object synchronizes the data from the source application connected to the SourceApp port.

Collaboration that invokes a workflow process

Implementing a synchronous activity

When a collaboration object communicates by implementing a synchronous activity, the SourceApp port can be connected to the entity source application connector or port connector. This type of collaboration object is configurable using the SYNC_FROM_SOURCE parameter. If the value of this parameter is set to "true" then the collaboration object synchronizes the data from the source application connected to the SourceApp port.

The DestinationAppRetrieve port can be connected to the entity destination application connector or port connector. This type of collaboration object is configurable using USE_RETRIEVE parameter.

This type of collaboration object may have multiple To ports based on the applications participating in this synchronization process.

If there are two To ports, they are named ToMain and ToSub. The synchronization process executes the ports in the following order: first ToMain, then ToSub.

If there are more than two To ports, they are named ToMain, ToSub1, ToSub2, etc. The synchronization process executes these ports in the following order: first ToMain, then ToSub1, ToSub2, and so on.

If the business object associated with the To port is different from the triggering business object, the port is named To<BusinessObjectName>.

Collaboration that implements a synchronous activity

Implementing an asynchronous activity

When a collaboration object communicates by implementing an asynchronous activity, the SourceApp port can be connected to the entity source application connector or port connector. This type of collaboration object is configurable using SYNC_FROM_SOURCE parameter. If the value of this parameter is set to "true" then the collaboration object synchronizes the data from the source application connected to the SourceApp port.

The DestinationAppRetrieve port can be connected to the entity destination application connector or port connector. This type of collaboration object is configurable using USE_RETRIEVE parameter.

For the collaboration object that sends the request, the From can be connected to the workflow request, and the To port can be connected to a long-running application. For the collaboration object that receives a response, the connections are reversed: the To port connects to the long-running application, and the From port connects to the workflow response.

Collaboration that implements an asynchronous activity

Retrieving a list

When a collaboration object communicates by retrieving a list, the DestinationAppRetrieve port can be connected to the entity destination application connector or port connector. This type of collaboration object is configurable using USE_RETRIEVE parameter. This type of collaboration object is designed to support request/response calls and workflow activity implementations.

If the collaboration object is intended for supporting a business process activity, set the From port to the WebSphere MQ Workflow connector, set the Return port also to WebSphere MQ Workflow connector and set the USE_RETURN property to "true".

The WebSphere Business Integration Collaborations for Telecommunications architecture assumes that this type of collaboration object is used in a JSP sequence using a server access interface. For this usage, configure the From port to an external type, connect the Return port to the Port Connector, and set the USE_RETURN property to "false".

Collaboration that retrieves a list

Developing Maps

The detailed development procedure for maps is described in the Map Development Guide. This section provides the requirements for deploying WebSphere Business Integration Collaborations for Telecommunications maps.

Maps between WebSphere MQ Workflow application-specific business objects and generic business objects

The WebSphere Business Integration Collaborations for Telecommunications solution provides similar data models for generic business objects and WebSphere MQ Workflow data structures. However, application-specific business objects generated by the FDLBOGen Tool are different from generic business objects.

The following example shows how these business objects differ from one another. This example uses the following FDL data structures.

  STRUCTURE Record 
    'ItemA': 'Item';
    'ItemB': 'Item' (2);
  END Record
  STRUCTURE Item
    'Name': 'String';
    'Type': 'String';
  END Item

If you create the application-specific business object for Record using FDLBOGen and use WebSphere MQ Workflow_Struct_ as the specified prefix, the following three application-specific business objects are generated:

WebSphere MQ Workflow_Struct_Record (supported verbs: create, retrieve, update, delete)
Element Name Element Type
ItemA WebSphere MQ Workflow_Struct_Record_ItemA
ItemB WebSphere MQ Workflow_Struct_Record_ItemB (Cardinality n)
ObjectEventId String

WebSphere MQ Workflow_Struct_Record_ItemA
Element Name Element Type
Name String
Type String
ObjectEventId String

WebSphere MQ Workflow_Struct_Record_ItemB
Element Name Element Type
Name String
Type String
ObjectEventId String

In the WebSphere Business Integration Collaborations for Telecommunications solution, GBOs would be provided in the following manner:

Record (supported_verb: may be different from create, retrieve, update, delete)
Element Name Element Type
ItemA Item
ItemB Item (Cardinality n)
ObjectEventId String

Item
Element Name Element Type
ObjectId String (key)
Type String
ObjectEventId String

Development summary

The following points apply to the development with the WebSphere Business Integration Collaborations for Telecommunications solution:

System management

There is no integrated system management capability in the current release. Administrators can use the following system management tools provided by WebSphere MQ Workflow and IBM WebSphere InterChange Server:

For more detailed information, refer to the documentation for WebSphere MQ Workflow and IBM WebSphere InterChange Server.

Localization and globalization

Both WebSphere MQ Workflow and IBM WebSphere InterChange Server are DBCS enabled and their infrastructures also support localization. The artifacts of the current release of IBM WebSphere Business Integration Collaborations for Telecommunications are DBCS enabled, but are not translated.

For more information on  the implementing localization and globalization, refer to the localization-enabled API of the BaseCollaboration class.

Assembling end-to-end business processes

To get an end-to-end view of business processes you need to integrate individual business process together. The following diagram shows the relationships among the business processes provided by WebSphere Business Integration Collaborations for Telecommunications. Fault resolution and Service usage do not appear in the following diagram, as they do not have defined relationships with the other business processes.

Relations among Business Processes

WebSphere Business Integration Collaborations for Telecommunications has the following two patterns for relationships between multiple business processes:.

The containment relation means that a process is a subprocess of a parent process. This relation is shown with the <<contains>> stereotype in the diagram above.

The triggering condition relation means that a completion of a previous process invokes the current process.

To the extent that these processes are managed by WebSphere MQ Workflow system, the owner of a series of processes can monitor their progress.

If the scope of your business process integration does not fully implement the templates provided by the WebSphere Business Integration Collaborations for Telecommunications industry solution library, you may replace the provided templates with your own processes in your end-to-end scenario.

To replace a sub-process in a containment relationship, you need to trace your process with your own process tracking system. By doing this, you might lose the centralized capability of business process management. In this case, you can treat your existing process as an asynchronous activity in the WebSphere Business Integration Collaborations for Telecommunications parent process. To complete this type of implementation, you must develop at least two collaboration objects: one that invokes your process, and another that notifies WebSphere MQ Workflow when the process execution is complete.

All possible process replacements are summarized in the following table.

Process replacements
Relation Replacement target Required collaboration objects Description
Containment Parent Process 2 One collaboration object invokes the process, and the other provides a notification when the process is completed
  Sub Process 2 One collaboration object invokes the process, and the other provides a notification when the process is completed
Triggering Condition Previous Process 0 Changes the connector of the triggering port 
  Continuous Process 1 Invokes your process

Integrated monitoring and tracking views are not provided by the solution studio in this release. If you require this functionality, you may develop an aggregation view using other tools such as WebSphere Portal Server.

Security integration

For the WebSphere Business Integration Collaborations for Telecommunications solution, there are three security domains to be considered for security configuration:

Basically IBM WebSphere InterChange Server does not have its own security domain. It depends on MQ queue manager security domain. The MQ queue manager security domain delegates its security authentication to operating system or directory security service; such as LDAP. The WebSphere MQ Workflow has its own security domain, but can not be externalized. As a result, there is no integration point to a centralize directory security services.

If you want to activate security in all domains, you need to register a user id in the MQ Queue Manager security registry and the WebSphere MQ Workflow registry at the same time. Alternatively, application-level security might be the best choice. Application-level security means that the application which interacts with users provides its own authentication mechanism. The overall security mechanism depends on the application security check.

Business services

The complete set of business services provided by WebSphere Business Integration Collaborations for Telecommunications is listed below, grouped by business process use case.

Product development and retirement

The following business services are provided for the product development and retirement use case.

AddProduct

UpdateProductStatus

UpdateProduct

Customer order handling

The following business services are provided for the customer order handling use case.

AddCustomer

AddAccount

PreQualifyProductForCustomer

AddSalesOrder

CreateServiceOrderForSalesOrder

AddCustomerBillingAccount

UpdateSalesOrderStatus

UpdateServiceOrderStatus

AddBillableItem

BranchPoint

UpdateCustomer

UpdateAccount

UpdateSalesOrder

UpdateServiceOrder

Service configuration and activation: DSL

The following business services are provided for service configuration and activation (DSL) use case.

AddCustomerConfigRecord

InitiateConfigRequestToProvider

TestConfiguration

SetupService

UpdateServiceOrderStatus

UpdateSalesOrderStatus

Service configuration and activation: IDC

The following business services are provided for the service configuration and activation (IDC) use case.

CreateVLANProvisioning

ImplementServiceReature

InstallSoftware

UpdateSalesOrderStatus

Service configuration and activation: Wireless

The following business services are provided for the service configuration and activation (Wireless) use case.

CreateSubscriberHLR

CreateTemporaryPassword

UpdateSalesOrderStatus

Customer resource provisioning

The following business services are provided for the customer resource provisioning use case.

UpdateFieldWorkStatus

UpdateCustomerConfigRecord

AddBillableItem

UpdateCustomerBillingAccount

ActivateBillingCycle

Customer problem handling

The following business services are provided for the customer problem handling use case.

AddProblemRecord

UpdateCustomer

UpdateProblemRecord

UpdateProblemRecordStatus

Fault resolution

The following business services are provided for the fault resolution use case.

AssignTechnician

UpdateTroubleTicket

Copyright IBM Corp. 2002, 2003