This section tells how to perform tasks in the AquaLogic Service Bus Plug-in for WorkSpace Studio:
This section tells how to perform the following tasks:
See also the following information about working with other kinds of resources:
Edit resources using the built-in editors. For example, edit a proxy service by double-clicking its name in the Project Explorer.
Do not manually edit resource files as text or XML files. This can result in unpredictable behavior. Do not manually edit these resource types:
In the ALSB perspective, select File > New > ALSB Configuration Project to display the New AquaLogic Service Bus Configuration Project wizard. Enter information as appropriate.
In the ALSB perspective, select File > New > ALSB Project to display the New AquaLogic Service Bus Project wizard. Enter information as appropriate.
Note: | You can create an ALSB project in an ALSB configuration project only. |
In the ALSB perspective, select File > New > Custom Resource to display New Custom Resource wizard. Enter information as appropriate.
Note: | You can create a custom resource in an ALSB project only. |
In the ALSB perspective, select File > New > JNDI Provider to display the New JNDI Provider Resource wizard. Enter information as appropriate.
Note: | You can create a JNDI provider resource in an ALSB configuration project only. |
In the ALSB perspective, select File > New > MFL to display the New Message Format File wizard. Enter information as appropriate.
Note: | You can create a message format file in an ALSB project only. |
In the ALSB perspective, select File > Export to display the Export wizard. See:
In the ALSB perspective, select File > Import to display the Import wizard. See:
In the ALSB perspective, select File > New > Server to display the New Server wizard.
In the ALSB perspective, select File > New > Service Account to display the New Service Account Resource wizard.
Note: | You can create a service account resource in an ALSB project only. |
In the ALSB perspective, select File > New > Service Key Provider to display the New Service Key Provider Resource wizard.
Note: | You can create a service key provider resource in an ALSB project only. |
Note: | You can create an SMTP server resource in an ALSB configuration project only. |
In the ALSB perspective, select File > New > XQuery Transformation to display the XQuery/XSLT Expression Editor. Enter information as appropriate.
Note: | You can create an XQuery transformation resource in an ALSB project only. |
In the ALSB perspective, select File > New > XSL Transformation to display the XPath Expression Editor.
Note: | You can create an XSL transformation resource in an ALSB project only. |
The following topics describe how to create and work with business services in the ALSB plug-in.
In the ALSB perspective, select File > New > Business Service to display the New AquaLogic Business Service wizard. See:
Note: | You can create a business service in an ALSB project only. |
The following topics describe how to create and work with proxy services in the ALSB plug-in.
In the ALSB perspective, select File > New > Proxy Service to display the New AquaLogic Proxy Service wizard. See:
Note: | You can create a proxy service in an ALSB project only. |
The following topics describe how to create and work with alert destinations in the ALSB plug-in.
Note: | You can create an alert destination in an ALSB project only. |
The following topics describe how to add and configure nodes and actions to proxy service message flows.
When you create a proxy service, a message flow is created by default, with an empty starting node. The process for constructing the message flow follows this general pattern:
Alternatively, you can right-click a node or action in the Message Flow Editor to display menus of nodes and actions that can be inserted in that location. The menu contains one or more the following:
Alternatively, you can select a node or an action from the Outline view. To open the Outline view, in the ALSB perspective, select Window > Show View > Outline.
Use the alert action to generate alerts based on message context in a pipeline, to send to an alert destination.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
Use an assign action to assign the result of an XQuery expression to a context variable.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the assign action
Use a conditional branch node to specify that message processing is to proceed along exactly one of several possible paths, based on a result returned by an XPath condition.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To add a conditional branch node
To configure the conditional branch node
Use a delete action to delete a context variable or a set of nodes specified by an XPath expression.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the delete action
Use a dynamic publish action to publish a message to a service specified by an XQuery expression.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To add a dynamic publish action
To configure the dynamic publish action
Use a dynamic routing action to assign a route for a message based on routing information available in an XQuery resource.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To add a dynamic routing action
To configure the dynamic routing action
Use an error handler to specify what should happen if an error occurs in a specific location in the message flow.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the error handler
Use the for-each action to iterate over a sequence of values and execute a block of actions.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the for-each action
Use an if-then action to perform an action or a set of actions conditionally, based on the Boolean result of an XQuery expression.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the if-then action
Use an insert action to insert the result of an XQuery expression at an identified place relative to nodes selected by an XPath expression.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the insert action
Use a Java callout action to invoke a Java method or an EJB business service from within the message flow.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the Java callout action
Use the log action to construct a message to be logged and to define a set of attributes with which it will be logged.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
Use a MFL (Message Format Language) transform action to convert message content from XML to non-XML, or vice versa, in the message pipeline.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the MFL transform action
Use an operational branch node to configure branching based on operations defined in a WSDL.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To add an operational branch node
To configure the operational branch node
Use a pipeline pair node to define request and response processing.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the pipeline pair node
Use a publish action to identify a statically specified target service for a message and to configure how the message is packaged and sent to that service.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the publish action
Use a publish table action to publish a message to zero or more statically specified services.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the publish table action
Note: | There is a nesting limit of four cumulative levels in the stage editor. If you attempt to add a fifth level, nesting action is not displayed. Cumulative levels include all branching actions: if... then... conditions, publish tables, and route tables. For example, you can have 2 levels of conditionals, then a publish table with a route table inside of it, bringing the total to 4 levels. If you attempt to add another conditional (to the last publish table), the conditional is not displayed. |
Use the raise error action to raise an exception with a specified error code (a string) and description.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the raise error action
Use the rename action to rename elements selected by an XPath expression without modifying the contents of the element.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the rename action
Use a replace action to replace a node or the contents of a node specified by an XPath expression. The node or its contents are replaced with the value returned by an XQuery expression.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the replace action
Use the reply action to specify that an immediate reply be sent to the invoker.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
Use the report action to enable message reporting for a proxy service.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the report action
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the resume action
Use the route node to handle request and response dispatching of messages to and from business services.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
Use a routing action to identify a target service for the message and configure how the message is routed to that service.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the routing action
Use a routing options action to modify any or all of the following properties in the outbound request: URI, Quality of Service, Mode, Retry parameters, Message Priority.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To add a routing options action
To configure the routing options action
Use a routing table to select different routes based upon the results of a single XQuery expression. A routing table action contains a set of routes wrapped in a switch-style condition table.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the routing table action
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To add a service callout action
To configure the service callout action
Use the skip action to specify that at run time, the execution of the current stage is skipped and the processing proceeds to the next stage in the message flow.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
Use a stage node as a container for actions in a message flow.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
Use a transport header action to set header values in messages.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To add a transport headers action
To configure the transport headers action
Use a validate action to validate elements selected by an XPath expression against an XML schema element or a WSDL resource.
Display the message flow for the desired proxy service. See Constructing Proxy Service Message Flows.
To configure the validate action
MQ connections are sharable resources that can be reused across multiple MQ proxy and business services. MQ proxy and business services must connect to a MQ queue manager before accessing an MQ queue. MQ Connection resources provide the connection required for connecting to an MQ queue manager.
Each MQ Connection resource has a connection pool. Every business or proxy service using a given MQ Connection resource to get a connection to a given queue manager uses the same connection pool that was created for that resource. Thus, multiple business services and proxy services using the same queue manager share a connection pool.
To learn more about ALSB MQ Connection resources and native MQ transports, see the Native MQ Transport User Guide.
To learn more about WebSphere MQ Fundamentals, see http://www.redbooks.ibm.com/redbooks/SG247128/wwhelp/wwhimpl/java/html/wwhelp.htm.
In ALSB, MQ connections are created as custom resources. Therefore, to add an MQ connection, you must create it as a custom resource, as follows:
Universal Description, Discovery and Integration (UDDI) registries are used in an enterprise to share Web Services. UDDI provides a framework in which to classify your business, its services, and the technical details about the services you want to expose.
Publishing a service to a registry requires knowledge of the service type and the data structure representing that service in the registry. A registry entry has certain properties associated with it and these property types are defined when the registry is created. You can publish your service to a registry and make it available for other organizations to discover and use. Proxy services developed in ALSB can be published to a UDDI registry. ALSB can interact with any UDDI version 3.0-compliant registry.
See also UDDI in the AquaLogic Service Bus User Guide.
Note: | You can add a UDDI registry only to an ALSB configuration project only. |
Note: | You can add a UDDI registry in an ALSB configuration project only. |
For help using UDDI Register Access in the Service Consumption dialog, press F1, or search in the help system for “Service Consumption dialog.“
This section provides instructions for creating and configuring Split-Joins. Following are the primary topics in this section:
The Split-Join is a mediation pattern that can be used by a transport typed business service in an ALSB message flow. Split-Join allows you to send message requests to multiple services concurrently, thus enhancing performance in comparison to sending them sequentially. Split-Join achieves this task by splitting an input message into individual messages, routing them concurrently to their destinations, and then aggregating the responses into one overall message.
You design a Split-Join in the WorkSpace Studio Split-Join editor, then export it to the ALSB console for testing and production.
Note: | In the ALSB console, a Split-Join is associated with a business service using the Flow transport protocol. Therefore, the Split-Join has a .flow file name extension in WorkSpace Studio even though it is always referred to simply as a “Split-Join” in this document. |
There are two types of Split-Join pattern: static Split-Join and dynamic Split-Join, as described in Designing a Split-Join.
For more information on invoking a business service from an ALSB message flow, see Proxy Services: Message Flow in the ALSB console help system.
There are two Split-Join patterns, the Static Split-Join and the Dynamic Split Join.
The Static Split-Join can be used to create a fixed number of message requests (as opposed to an unknown number). For instance, a customer places an order for a cable package that includes three separate services: internet service, TV service, and telephone service. In the Static use case, you could execute all three requests in separate parallel branches to improve performance time over the standard sequential execution.
The Dynamic Split-Join can be used to create a variable number of message requests. For instance, a retailer places a batch order containing a variable number of individual purchase orders. In the Dynamic use case, you could parse the batch order and create a separate message request for each purchase. Like the Static use case, these messages can then be executed in parallel for improved performance.
Split-Joins potentially include the following tasks as part of their initial setup:
Every Split-Join is based upon a WSDL operation. When you first create a Split-Join, you will be asked to browse to the appropriate WSDL file and to select this operation as part of the creation process. You can create this WSDL file in WorkSpace Studio.
Every Split-Join will be used by a transport typed business service, which, in turn, is invoked by a proxy service. You cannot export or test your Split-Join until you have created this business service. If it already exists, you can import it into WorkSpace Studio, or, if it does not exist, you can create it in WorkSpace Studio or the ALSB console. If you want to get started on your Split-Join before you create the business service, you can generate the business service automatically after you create the Split-Join.
Suppose you want to design a new Split-Join called Service Availability that handles orders for a telco’s cable service package including TV, phone, and internet service. The idea is for the Split-Join to receive an incoming package order and to reply with an order acknowledgement for each type of service. In this case, Service Availability is designed as a Static Split-Join because there are three message requests per order, one for each type of service. In this particular example the customer requests only TV and DSL service.
Creating the Service Availability Split-Join may include the following tasks:
4. Adding an Assign for Each Branch
5. Adding an Invoke External Service
6. Adding an Assign for Each Branch
7. Exporting and Testing the Split-Join
Create a new Split Join based on the WSDL operation you want to use for placing the order. In this case the WSDL operation we want is called “telecom.”
After you select the WSDL operation, a skeleton of the newly created Split-Join appears in the Split-Join editor, as shown in the following figure. It consists of a Start Node, a Receive, a Reply. The labels are then edited in the general properties tab to better reflect the specific function of each node in this particular Split-Join.
The Start Node contains both a Request Variable and a Response Variable that have been determined by the WSDL operation initially selected. The Receive receives the incoming request message (in this case for the three or fewer different kinds of cable service), and the Reply generates a response message and sends it back to the client.
Note: | The Receive node requires no further configuration. Similarly the Reply requires no further configuration, unless to generate an error fault--which is not the case in this scenario (see Configuring a Reply for more information on generating faults). |
The first Assign, Prepare Output Message, contains an Assign operation that prepares the Response Variable in a form such that the later nodes can work on the data within it (that is, Copy/Insert/Assign/Replace/Delete the data). This output message is relayed to the final Reply node in the Split-Join and, in turn, returned to the original client.
The Parallel Node contains two main branches, one to check cable TV availability and one to check DSL availability. Each branch is composed of a number of actions, the sequence and general configuration being the same for both branches.
The first Assign in each Parallel Branch, Prepare Input Address, copies the incoming customer address data into a Variable that is referenced to check the availability of the service at that location. The Assigns are the same for each branch and would be for additional branches as well.
An External Service is then invoked to check whether the requested service type is available at the customer’s location. Each branch contains one Invoke External Service, Check Cable TV Availability and Check DSL Availability. Each invocation calls an External Service, which compares the customer’s address (stored in the Variable initialized in the previous step) to the availability of the service at that location. The result is then stored in an output Variable that is passed on to the final Assign in the Branch below.
The final two Assigns, Update Cable TV Status in Output Message and Update DSL Status in Output Message, take the results of the external service invocations and put them into the output message using a Replace operation. The aggregated response are then sent to the original client in the final Reply node, which requires no further configuration.
After you design the Split-Join, you can export it to the ALSB console for testing and production.
Suppose that you want to design a Split-Join that handles a batch order from a retailer containing a variable number of individual purchase orders (as opposed to a fixed number of orders). The idea is for the Split-Join to receive the batch order and to reply with an order acknowledgement for each order within. This would be a Dynamic Split-Join because the number of individual purchase order requests is variable and unknown at design time.
Creating this Split-Join may include the following tasks:
5. Adding an Invoke External Service
8. Exporting and Testing the Split-Join
Create a new Split Join based off of the WSDL operation you want to use for placing the order. In this case the WSDL operation we want is called “batchOrders.”
After the operation is selected, a skeleton of the newly created Split-Join appears in the Split-Join editor consisting of a Start Node, a Receive, a Reply. The labels are then edited in the general properties tab to better reflect the specific function of each node in this particular Split-Join.
The Start Node, Order Placement, contains both a request variable, inputVar, and an response variable, outputVar. The Receive, Receive Batch Order Request, will initialize the contents of the Request Variable (in this case purchase orders), and the Reply, Reply Order Placement, will send a response, based on the order acknowledgements aggregated into the Response Variable, back to the client. In this example Order Placement also contains a callout to an External Service, “Order” that will be invoked to approve individual orders.
Note: | The Receive node requires no further configuration. Similarly, the Reply requires no further configuration, unless you would like to generate an error fault—which is not the case in this scenario (see Configuring a Reply for more information on generating faults). |
The first Assign, Prepare Output Message, contains an Assign operation that prepares the response variable (here labeled an “Output Message” for readability) in a form such that the later nodes can work on the data captured within it (that is, Copy/Insert/Assign/Replace/Delete into the Variable). In this case, that data would consist of order acknowledgments and/or errors.This Output Message is relayed to the final Reply node in the Split-Join and, in turn, returned to the original client.
The For Each, Iterate Through Orders, contains logic that will parse through each order in the batch, send it to an external proxy for approval, and capture an order acknowledgment in response. If there is a problem with an order, an error is sent from the invoked proxy and captured in the Error Handler. The following figure depicts the entire scope of the For Each logic.
The Assign, Prepare Purchase Order, copies the incoming purchase order requests into a variable that is referenced to check approval of the order in the next step.
An external service, Check Order Availability, is then invoked to approve each individual purchase order. If the order is accepted, the service responds with an order acknowledgment. If the order is not accepted, the service responds with an error.The result is then stored in an output variable that is passed on to the final Assign in the next step.
The final Assign, Update Order Status in Output Message, takes the results of the external service invocation and copies them into the output message using an Insert operation. The aggregated response is then sent to the original client in the final Reply node, which requires no further configuration.
The Error Handler captures any Errors returned by the invoked service. It takes these errors and inserts them into the output message using an Assign operation.
After you design the Split-Join, you can export it to the ALSB console for testing and production.
In order to create a new Split/Join, you must have access to a WSDL containing the operation upon which to base the Split-Join. The Split Join must be created in an existing ALSB project within an existing ALSB configuration project.
A basic Split-Join is created and visually represented as a diagram in the Design View. By default, it consists of a Start Node, a Receive, and a Reply. The Start Node contains the Request and Response Variables introspected from the WSDL operation. The Receive is used to receive incoming request messages. The Reply is used to send response messages.
The Start Node is generated automatically whenever you create a new Split-Join. It is the starting point from which all the other nodes proceed. Configuring a Start Node can include the following tasks:
General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.
Variables in the Start Node store data that can be referenced globally, that is by any node in the Split-Join. By default, every Start Node is assigned both a request and a response variable when the Split-Join is initially created. From the Start Node, you can either create a new global variable or edit an existing global variable.
To create a new global variable:
Note: | You may need to drill down into the hierarchy to select a Schema or Message Type variable. |
If it is not already open, expand the content area to the left by clicking the arrow to the left of the Start Node icon. The newly created variable appears in the Variables field along with any other global variables. To view the details of any variable, simply select it and its structure will appear in the Properties view.
To edit an existing global Variable:
If it is not already open, expand the content area to the left of the Start Node icon. The newly created variable appears in the Variables field along with any other global variables. To view the details of any variable, simply select it and its structure will appear in the Properties view.
The External Services listed in the Start Node are those invoked outside of the context of the Split-Join. They are specified in an Invoke External Service but listed here for convenience.
To view External Services, expand the content area to the left of the Start Node by clicking the arrow to the left of the Start Node icon. When an External Service is selected, a dashed blue arrow appears pointing to the Invoke External Service associated with the service, and the service’s location appears in the Properties view.
A Receive is generated automatically whenever you create a new Split-Join. The purpose of the Receive is to place incoming request data in a variable and make the contents available for later nodes to use. Configuring a Receive can include the following tasks:
The Operation is based upon the initial WSDL selection for the overall Split-Join. It is displayed in the Properties View for reference.
You must define the Incoming Message Variable the Receive will initialize. This can be done in two ways:
To create a new Message Variable, select Create Message Variable from the Message Variable menu. The Create Message Variable Dialog appears:
Note that Message Type Namespace and Message Type are displayed automatically on the Properties page once the variable is defined.
General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.
The Assign is used for data-manipulation including initializing and updating a variable. It is composed of a set of one or more operations that can be added and/or edited in the Assign toolbar. Configuring an Assign can include the following tasks:
Assign operations include Assign, Copy, Delete, Insert, and Replace. Every Assign is composed of one or more of these operations, which you can add to the Assign using the Assign toolbar.
In addition, each operation has its own configuration dialog/editor.
Note: | The Assign operations in the Split-Join editor are essentially the same as the corresponding actions in the WorkSpace Studio Message Flow editor. However, one important difference is that when you are using the XQuery\XSLT or XPath Editors to edit expressions in the Split-Join context, only variables and namespaces internal to the Split-Join are available. |
A brief explanation of each operation follows:
For more information on configuring the Assign, see Split-Join Properties View – Assign.
Note: | Unlike the ALSB delete, only an XPath expression may be deleted in a Split-Join, not the entire variable. For more information on configuring the Delete operation, see Delete Action Dialog. |
For more information on configuring the Insert operation, see Insert Action Dialog.
For more information on configuring the Replace operation, see Replace Action Dialog.
Adding an operation to the Assign involves the following steps:
Note that you can edit a configured operation by double-clicking the operation in the Assign Operations table or selecting an operation and clicking the Edit button in the toolbar.
The Copy operation allows you to copy the information specified by an XPath 1.0 expression from a source document to a destination document. It is an operation unique to the Split-Join editor. Adding a Copy operation to the Assign involves the following steps:
General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.
The Invoke External Service is used to invoke external, WSDL-based business or proxy services. Configuring an Invoke Service can include the following tasks:
An operation must be selected upon which to base the Invoke External Service. You must select this operation before you can configure Input and Output variables. To select an operation:
Note: | Clicking a selected Service Location will open the file. |
An Invoke External Service requires both an Input Variable and an Output Variable, unless it is a one-way invocation. The procedure to configure these variables is essentially the same. Either type of variable can be global (that is, available within the entire Split-Join) or local (that is, available within a particular context Scope.) To define either an Input or Output variable:
To create a new Message Variable:
Note that Message Type Namespace and Message Type are displayed automatically on the properties page once a variable is defined.
General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.
The Parallel creates a fixed number of configured parallel branches. Each branch has its own Scope which in turn can contain any number of nodes. Configuring a Parallel can include the following tasks:
The Parallel is essentially a placeholder for a fixed number of processing branches, each with its own scope. Two branches are automatically generated by default. An individual scope may contain unique processing logic according to your construction; simply drag the appropriate nodes into the Scope. You may add additional branches with the Add Scope button.
General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.
The For Each is used to create conditional logic for iterating through a variable number of requests. It is primarily used to create dynamic Split-Joins. Configuring a For Each can include the following tasks:
Note: | The lowest possible starting counter value is “1.” |
Note: | The lowest possible starting counter value is “1.” |
General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.
The If Activity is used to provide conditional logic within a Split-Join. It is composed of a number of nodes that determine the behavior for the overall If activity. Each node must be individually configured. When you create an If activity, an If and an Else are automatically generated within it. You can add an unlimited number of Else If nodes with the Add Else If button.
Configuring an If Activity can include the following tasks:
The If provides a unit of conditional logic within the overall If activity. It is automatically generated when you create an If activity. Configuring an If can include the following tasks:
The If Activity executes conditional logic defined by an XPath 1.0 expression. Enter this condition in the Condition text field of the Condition tab, or click the browse button to launch and write the expression in the Xpath 1.0 Expression Builder.
If the condition in the If logic is met, a subsequent node or string of nodes will result. Add and configure any resulting nodes by dragging them in sequential order to a drop point beneath the If icon.
General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.
The Else If is used to provide additional logic within the context of an overall If. You can add an Else If every time you press the “Add Else If” button.
Configuring an Else If can include the following tasks:
The Else If uses conditional logic defined by an XPath 1.0 expression. Enter this condition in the Condition text field of the Condition tab or click the browse button to launch and write the expression in the Xpath 1.0 Expression Builder.
If the condition in the Else If logic is met, a subsequent node or string of nodes will result. Add and configure any resulting nodes by dragging them in sequential order to a drop point beneath the Else If icon.
General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.
The Else provides a final case of logic within the context of an overall If. It is automatically generated when an If is created. Configuring an Else can include the following tasks:
As the final case in the If’s logic, the Else requires no conditions to be met in order to execute. It will automatically execute resulting activities when invoked. Add and configure any resulting nodes by dragging them in sequential order to a drop point beneath the Else icon.
General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.
The Error Handler receives and handles errors. If it is attached to a Start Node, it is a “global” Error Handler and serves as a catch-all for the output of all local Raise Error nodes. If it is attached to a Scope, it only handles errors raised locally. To create an Error Handler:
Note: | It must be a Start Node or a Scope. |
The basic Error Handler is now configured, but you may need to add additional Assign, If, and/or Reply nodes to it depending on whether you wish to execute logic upon the received faults before sending a response.
The Raise Error generates an error that causes the Split-Join to stop normal processing. If the error is not handled using an Error Handler, the Split-Join will terminate and a Fault will be sent to the ALSB message flow. Configuring a Raise Error can optionally include documenting the nature of the error in the General Information tab.
General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with developer notes, or Documentation. General information is optional.
A global Reply is generated automatically whenever you create a new Split-Join. The purpose of the global Reply is to send a response back to the invoking ALSB message flow. However, you may also create a local Reply to an Error Handler. Configuring the Reply can include the following tasks:
The operation is based upon the initial WSDL selection for the overall Split-Join. It is displayed in the Properties view for reference.
The Reply can either send a Response or a Fault back to the client depending on how you configure the variable. The Fault options available vary depending upon whether the Reply is global or local.
Note: | Switching back and forth between the Response and Fault buttons will clear either configuration. For instance, if you have previously selected “Propagate SOAP Fault” for Fault configuration and you then switch to the “Response” configuration, “Propagate SOAP Fault” will be deselected. |
Given the available options as outlined above, select either a Response or a Fault for your Reply Variable.
If you select Response, you must define the Message Variable the Response will be assigned to. This can be done in two ways:
To create a new Message Variable, select Create Message Variable from the Message Variable menu. The Create Message Variable Dialog appears:
Note that Message Type Namespace and Message Type are displayed automatically in the Properties view once the variable is defined.
If you select Fault, you must specify either a WSDL Fault or propagate a SOAP Fault.
Note: | In some circumstances, no Faults or only a SOAP Fault will be available. See previous notes. |
If you select a WSDL Fault, you must specify the Fault by name and define the Message Variable that it will be assigned to.
To create a new Message Variable, select “Create Message Variable” from the Message Variable menu. The Create Message Variable Dialog opens:
Note that Message Type Namespace and Message Type are displayed automatically on the properties page once a variable is defined.
If you select Propagate SOAP Fault, the SOAP Fault specified in the parent Error Handler will automatically be propagated in the Reply. There is nothing else to be configured
General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.
A Scope is a container that groups various elements together. The container creates a context that influences the behavior of its enclosed elements. Local Variables and the Error Handler defined within the Scope are restricted to this context. However, some nodes within the scope may operate both locally (that is, within the Scope) and globally (that is, outside of the Scope.) For instance, an Invoke External Service within a certain Scope might call upon an service external to the Scope’s context.
You can export and test a Split-Join on an ALSB server provided that it is associated with a transport typed business service. Exporting and testing a Split-Join can include the following tasks:
A Split-Join is used by a particular transport typed business service. If you do not have an appropriate business service, you must create one before you can export or test your Split-Join. There are two ways to create a business service:
After you create the business service, you can export the Split-Join provided that it has no errors.
Note: | It is a helpful practice to place the associated business service in the same ALSB project as the Split-Join. It can also be useful to give the business service the same name as the Split-Join so that they are easily correlated. |
Split-Joins without errors can be exported to an ALSB server.
Note: | Errors appear in the Problems view of the Split-Join editor. If you try to export a Split-Join with errors, the export fails. |
There are three ways to export a Split-Join:
It is possible to export a Split-Join directly from the Business Service menu. However, because exporting by this method automatically launches the ALSB Test Console, it is useful if you want to both export and test. Exporting from the Business Service menu involves the following steps:
A Split-Join can be auto-exported to an ALSB server. If you use this method, you must manually launch the ALSB console in order to test the exported files. Auto-exporting involves the following steps:
A Split-Join can be manually exported to an ALSB server. If you use this method, you must manually launch the ALSB console to test the exported files. Manually exporting involves the following steps:
Note: | A quick way to access the ALSB console from the IDE is to select Launch ALSB Administration Console from the server menu. (Right-click the appropriate server in the Servers view.) |
You can test a Split-Join by executing the business service that uses it in the ALSB Test Console. This can either be done within the Split-Join editor or by exporting the Split-Join to an ALSB server. To test the Split-Join within the IDE, you need to export the files using the menu for the business service that uses the Split-Join.
You can export and test a Split-Join directly from the Business Service menu. If you use this method, the export happens in the background while the ALSB Test Console launches. Exporting from the Business Service menu involves the following steps:
Click Finish, and the ALSB Test Console will launch. You can now test the business service.
Note: | Although only the ALSB Test Console is displayed at this point, the entire Split-Join has been exported to the ALSB server. |