Implementing the solution

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

Implementing a WebSphere Business Integration Collaborations for Healthcare 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 Healthcare 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 Healthcare 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 Healthcare 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 Health Level Seven (HL7) Version 2.4 message framework. 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 use case scenarios are provided in the overview and use case document. The domain analyst uses the overview and use cases to help determine whether the WebSphere Business Integration Collaborations for Healthcare business processes are sufficient to meet requirements defined by the organization.

WebSphere Business Integration Collaborations for Healthcare provides the following overview and use case document:

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.

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 Healthcare 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 Healthcare 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 Healthcare industry solution library provides a set of a IBM WebSphere Business Integration Collaboration templates targeted specifically to healthcare processes.

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. 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 Healthcare provides the following documents for the collaboration templates included in the industry solution library:

HL7-based collaboration templates

HL7-supporting collaboration templates

Generic business object templates

You should also examine the generic business objects used in the business process to assess their suitability for 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 Healthcare collaboration template documents provide links to top-level generic business object templates included in the industry solution library. These top-level generic business object documents in turn provide links to child generic business objects. Many other generic business objects not used in the samples provide rich support for the HL7 v2.4 Messaging Standard.

Installation

Before you can customize the WebSphere Business Integration Collaborations for Healthcare templates, you must install IBM WebSphere MQ Workflow Buildtime and IBM WebSphere InterChange Server. To install these products, refer to the installation guide for each of product.

The artifacts included in the WebSphere Business Integration Collaborations for Healthcare 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 JAR files can be imported using the System Manager. 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 its user interface.

For complete installation instructions, see Installing the solution.

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 Healthcare 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 Healthcare 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.

WebSphere Business Integration Collaborations for Healthcare 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 (www.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. If no existing collaboration template meets your requirements, you can develop a new collaboration template that extends an existing one. Refer to the WebSphere InterChange Server System Implementation Guide for more information on developing collaboration templates.

WebSphere Business Integration Collaborations for Healthcare also provides many useful generic business objects for the healthcare industry. You can use these generic business objects to work with new collaboration templates that you develop. 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 WebSphere InterChange Server 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 WebSphere InterChange Server System Implementation Guide for information on using IBM WebSphere InterChange Server tools to design and implement application-specific business objects and maps. As shipped, WebSphere Business Integration Collaboration for Healthcare Transaction does not use traditional ASBOs or maps. It uses generic business objects in its implementation.

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 Healthcare 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 tests 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 input 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 JavaTM 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, 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 www.ibm.com/software/ts/mqseries/txppacs/wa04.html 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 WebSphere InterChange Server System Implementation Guide.

Deployment

All software artifacts of the WebSphere Business Integration Collaborations for Healthcare industry solution library can be exported from Buildtime or the WebSphere Business Integration System Manager environments. Upon completion of the customization and development phase, you will have produced the following artifacts:

All jar files can be imported using the System Manager. 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 healthcare solution.

Exception handling

WebSphere Business Integration Collaborations for Healthcare uses WebSphere MQ Workflow to manage business processes. This section provides general concepts for error handling and practical examples of how to apply error handling.

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.

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 to avoid exceptions or subsequent automatic exception handling. Many policies can be applied to resolve exceptions, including the following:

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 subflow that contains the original extracted sequence and a continuous branch decision activity (shown in the second diagram).

Original  sequence

Subflow diagram

Forward recovery

A collection of activities can 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 shown 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 subtasks among related applications.

Forward recovery diagram

User interactions

User interactions allow human participants to interact with the business process management system. The WebSphere Business Integration Collaborations for Healthcare 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 using 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 work lists, 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.

Diagram of simple user interaction

Common utilizations of this simple type of user interaction in the WebSphere Business Integration Collaborations for Healthcare 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 JavaServer PageTM (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.

The SupportPac WA83: Rapid Deployment Wizard (see www.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 www.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. Calling a collaboration object is described in the Server Access Interface Development Guide for WebSphere InterChange Server.

IBM WebSphere Business Integration Adapter for MQ Workflow configuration

In the WebSphere Business Integration Collaborations for Healthcare 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 with 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.

For more detailed information about the configuration, refer to the WebSphere Business Integration 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 Healthcare solution. For complete information on the adapter, refer to the WebSphere Business Integration Adapter for WebSphere MQ Workflow User Guide.

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

Meta-Object Business Objects

The container business object contains the following structures.

Activity Implementation Request

Business object level application specific information:

  MO_MQWorkflow_ContainerInfo=ContainerInfo
  MO_MQWorkflow_ActivityRequest=ActivityRequest
Workflow Activity Implementation Request BO Format
Element Name Element Type Description
Input_name MQWF_Struct_xxxx 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. See the following table for more details.
ObjectEventId String  
MO_WebSphereMQWorkflow_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:

  MO_MQWorkflow_ActivityResponse=ActivityResponseMO
Workflow Activity Implementation Response BO Format
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 MQWF_Struct_xxxx This business object corresponds to the WebSphere MQ Workflow output container.
ObjectEventId String  
MO_MQWorkflow_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.

Process Invocation
Element Name Element Type Description
ProcessTemplate_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.
Item MQWF_Struct_xxxx This business object corresponds to the WebSphere MQ Workflow container.
ObjectEventId String  
MO_MQWorkflow_ProcessTemplateConfig
Element Name Element Type Description
ProcessTemplateName String  
ProcessInstanceName String  
KeepName String  
UserId String  
ExecutionMode String For ProcessTemplateCreateAndStartInstance 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  

Connector uses

The connector enables a collaboration object to monitor and control the status of a WebSphere MQ Workflow process using MO_MQWorkflow_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 each utilize the XML API to communicate with the Workflow server. The verb 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 Healthcare 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 WebSphere Business Integration Adapter for WebSphere MQ Workflow guide.

XML API Verb Processing

The connector uses the XML API to process the verb between WfMessage and business object as follows:

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 status to Workflow

    Diagram showing WebSphere MQ 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.

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 a business object, and then sends it to the WebSphere InterChange Server.
  4. A collaboration object that subscribes to this type of event executes the defined process and then calls the WebSphere MQ Workflow connector using another port with a return business object.
  5. The WebSphere MQ Workflow connector converts the return business object to an ActivityImplInvokeResponse message.
  6. The WebSphere MQ Workflow connector posts a message to the response queue to complete the activity.
  7. When the WebSphere MQ Workflow connector posts a message successfully, it returns status to Workflow.

    Diagram showning 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 a business object, and then sends it to the WebSphere InterChange Server.
  4. A collaboration object subscribed to this type of events navigates through the defined process and calls the application connector that handles a long-running activity asynchronously.
  5. Once the long-running function processing completes, the appropriate connector detects the completion event and sends the response back to the IBM WebSphere InterChange Server as a 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 business object to an ActivityImplInvokeResponse message.
  8. The WebSphere MQ Workflow connector posts a message to the response queue to complete the activity.
  9. When the WebSphere MQ Workflow connector posts a message successfully, it returns status to Workflow.

    Diagram showing 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 multithreaded 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. Some of the collaboration templates provided by WebSphere Business Integration Collaborations for Healthcare either store or return a unique correlation ID.

Diagram showing correlation resolution in a synchronous activity

The diagram below 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 entities further along in the process from the connector to return the correct correlation ID.

 Diagram showing correlation resolution in an asynchronous activity

The next diagram shows a flexible example of asynchronous activity.

The WebSphere MQ Workflow Asynchronous Response must set the value of ActImplCorrelID in the ActivityResponseMO.

Diagram showing correlation resolution with relationships and maps

User authentication

For the WebSphere Business Integration Collaborations for Healthcare 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.

WebSphere MQ Queue Manager

The WebSphere MQ Queue Manager security domain delegates user authentication functions to the operating system (Microsoft(R) Windows(R) 2000 or AIX, for example). In other words, you need to register user IDs in the operating system in 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 must register in the user registry to gain access. If the security is turned on, any program activities performed by a User-defined Program Execution Server (UPES) should be authenticated.

There are two possible methods to have collaboration objects control WebSphere MQ Workflow process instances. One method is to invoke the workflow Java APIs for suspend, resume, delete, and retrieve operations. For the start operation you must use the XML API. The WebSphere MQ Workflow connector has user ID and 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 in the userid field of the MO_MQWorkflow_ProcessTempleteConfig business object.

System management

There is no integrated system management capability in the current release of WebSphere Business Integration Collaborations for Healthcare. 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 libraries for WebSphere MQ Workflow and IBM WebSphere InterChange Server.

Security integration

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

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

If you want to activate security in all domains, you must register a user ID in the WebSphere MQ queue manager security registry and the WebSphere MQ Workflow registry at the same time. Alternatively, application-level security might be a better choice. Application-level security means that the application that interacts with users provides its own authentication mechanism. The overall security mechanism will depend on the application security check.

Copyright IBM Corp. 2002, 2003