Using the store-and-forward feature in WebSphere Process Server V7.0

This tutorial describes the new store and forward feature in WebSphere® Process Server V7, and uses several application scenarios to show you how to use it for smoother processing of application requests.

Share:

Phani Madgula (mabalaji@in.ibm.com), Software Developer, IBM

author imagePhani Madgula is currently working for WebSphere Process Server Support at the India Software Labs (ISL). He has 7 years of experience at IBM. He worked in various product teams, including WebSphere Application Server Community Edition, WebSphere Business Integration Adapters, and DB2. He has experience in developing JEE applications, product support, and database administration. He is an Oracle9i certified professional.



16 June 2010

Also available in Chinese Spanish

Introduction

When processing asynchronous requests in previous releases of WebSphere Process Server (hereafter called Process Server), failed events will be generated if there are any runtime errors. The recovery system keeps generating the failed events as the requests flow into faulty or unavailable service that is throwing the runtime errors. Once the runtime errors are resolved, the administrator will have to resubmit the failed events using either the admin console or scripts that use the failed event manager (FEM) API. This is a resource intensive operation to generate and resubmit failed events. In Process Server V7.0, the problem is elegantly addressed by the introduction of the store-and-forward feature.

When a component calls a service and the service is unavailable, the runtime errors are thrown. These runtime errors result in failed events being generated in the case of asynchronous calls. Instead of generating the failed events for subsequent service calls, users can configure the store-and-forward feature on the appropriate import or export or component so that the requests are stored in the corresponding queues. These stored requests will not be submitted to the faulty or unavailable target service anymore. This avoids generating a large number of failed events. Once the target service becomes available, the stored requests can be relayed using the Store and Forward widget in the business space.

In this tutorial

The tutorial demonstrates the configuration of this feature in applications that run on Process Server V7.0. It presents various scenarios with sample applications that illustrate how the feature works at runtime. The business space widgets that correspond to the store-and-forward feature are presented.

The tutorial is divided into the following sections:

  • Introduction to store-and-forward feature
  • The store-and-forward feature in various business application scenarios
  • Exception specification in the store-and-forward configuration

Prerequisites

  • A good understanding of J2EE concepts.
  • Skilled in developing applications for WebSphere Process Server using WebSphere Integration Developer (hereafter called Integration Developer) and performing administrative activities on the server environment.
  • Knowledge of WebSphere MQ and its tools.

System requirements

The following environment is required to run the samples.

  • One Windows® XP® Service Pack 2 desktop with at least 2 GB of RAM
  • IBM® WebSphere Integration Developer V7.0.0.0 Fix Pack 1 with the test environment. You need to apply interim fix IZ72101 for the test environment.
  • IBM WebSphere Process Server V7.0.0.0 Fix Pack 1
  • WebSphere MQ V6.0

Duration

3 hours


Introduction to the store-and-forward feature

This section describes the store-and-forward feature and explains how to configure it on the applications. It also provides guidelines to configure the qualifier.

How the store-and-forward feature works

You can enable the store-and-forward feature in the applications by configuring the store-and-forward qualifier on the component that is invoked asynchronously. This component can be an import, SCA export, or an SCA component. You can configure it on all the interfaces of the component, a specific interface, or a specific operation. As part of this configuration, a runtime exception is also specified. You can configure the runtime exception differently for each configuration of the store-and-forward specified on various interfaces or operations of the component. The store-and-forward configurations, which are specified on various interfaces or operations, form into service control points in the business space widgets.

The idea of store-and-forward is, when there is a runtime exception in the request flow, the exception will be propagated until the first asynchronous point. If store-and-forward is configured on the component near the asynchronous point, the subsequent requests are stored at that asynchronous point instead of continuously generating failed events. When the runtime exceptions are resolved, the stored events can be replayed using the Store and Forward widget. The asynchronous points map to service control points.

When an application configured with store-and-forward is deployed to Process Server and the runtime validation is enabled, a runtime validator confirms that the qualifier is configured correctly. If there are any errors, the installation of the application is stopped. If there are any warnings, they are displayed in the log file and the installation of the application is allowed to continue. The rules for validation of this qualifier are specified by the store-and-forward runtime validator.

When the component on which store-and-forward is configured calls a service synchronously and the service throws runtime errors, a failed event is generated for the request. However, this failed event will also initiate the store for this component. If the failed event is retrieved in the admin console, the event qualifier column will have a value of "initiated store". The Store and Forward widget in the business space will indicate that store is initiated on the service control points of the component. The status will be set to “storing” for the service control points. The subsequent requests to the component will be stored in the queue corresponding to the component. Once the target service becomes available or the runtime errors are resolved, the status of the service control points can be set to “forwarding” in the Store and Forward widget. When the status is set to forwarding, the stored events will be forwarded to the target service for processing.

Configuring the store-and-forward feature for applications

Integration Developer is used to configure the store-and-forward qualifier. Note the following points when configuring the store-and-forward qualifier:

  • The qualifier can be configured on the following components:
    • SCA Export (cannot be configured on other exports)
    • Imports
    • SCA Component
  • In addition, on each component mentioned above, the qualifier can be configured separately on all the interfaces and separately on all the operations of an interface.
  • Each of the configurations is provided a name and forms a service control point. All the service control points will be displayed in the store-and-forward widget in the business space. See the “Configuration name” field in Figure 1.
  • The exception specification has to be provided for each store-and-forward configuration. It indicates which runtime exception has to trigger the store. If the component receives the exception other than one specified, the store will not be triggered. By default, the exception is ServiceUnavailableException. For more information, see Service Runtime Exception handling. See the illustration in Figure 1.
  • The exception specification includes how the configured exception is resolved in the wrapped exception that is received by the component. Usually, in the exception propagation, the root exception is wrapped in the higher level exceptions. The component receives this wrapped exception, which contains a chain of exceptions. The “Exception chain” combo box in Figure 1 specifies this value.
  • The exception specification includes a message to match in the received exception. In order to trigger the store, the message in the received exception matches the specified message. This is useful when configuring the custom runtime exceptions. See the “Message to match” field in Figure 1 .
  • The exception specification can also specify to trigger the store if the received exception is a subclass of the specified exception. This is useful when configuring the custom runtime exceptions. See the “Match types that inherit from this type” field in Figure 1.
  • Figure 1 provides various options that are available (as explained) while configuring the store-and-forward qualifier. Click EmployeeServiceComponent in the assembly diagram and navigate to the Properties > Details tab in the bottom.
    Figure 1. Configuring the store-and-forward feature
    Configuring the store-and-forward feature

Note that you cannot use store-and-forward for synchronous invocations. For more information about configuring the store-and-forward qualifier, see the Store and forward qualifier topic in the Information Center.


Application scenarios for the store-and-forward feature

This section introduces various business application scenarios where you can use store-and-forward. The behavior of the feature in each scenario is illustrated with a sample application that you can deploy on to the Process Server environment. All these applications are provided in a Project Interchange (PI) format so that they can be imported into Integration Developer and run on the test environment.

Scenario 1: Store-and-forward on asynchronous imports (JMS, MQ, MQJMS, GenericJMS)

This section discusses how the store-and-forward feature works with message binding imports. The business scenario and the sample application are explained below.

The XYZ computer manufacturing company has an assembly unit and an inventory division. The inventory division provides information about the availability of CPUs. The assembly unit requests inventory division for availability of a particular CPU and the quantity. The inventory division responds whether the requested quantity of the particular CPU is available or not. If the quantity is not available, it responds with the information as to when the requested quantity will be available. The inventory division accepts requests over WebSphere MQ transport. The clients have to send the requests to a specified queue on WebSphere MQ and retrieve the response at a later time. So, the request flow is a one-way operation. Figure 2 provides the assembly diagram.

Figure 2. Assembly diagram of the Inventory service
Assembly diagram of the Inventory service

From the above assembly diagram, the CPUInventory component is exported as CPUInventoryExport with MQJMS export bindings. The AssemblyUnit component calls the CPUInventory component through CPUInventoryImport with MQJMS import bindings. The store-and-forward qualifier is configured on the CPUInventoryImport. Figure 3 shows the store-and-forward qualifier configured on the import.

Figure 3. Store-and-forward qualifier on CPUInventoryImport
Store-and-forward qualifier on CPUInventoryImport

Sometimes, there are unaccepted outages, which make WebSphere MQ unavailable for service. In these situations, if the AssemblyUnit calls the CPUInventory component through CPUInventoryImport, the import fails to connect to WebSphere MQ. This generates a failed event. Since store-and-forward is configured on the import, the first failed event will also initiate the store. The subsequent requests from the import are stored on the import queue. This way, the requests are generated, irrespective of whether WebSphere MQ transport is available or not. Once the WebSphere MQ service is back online, the stored requests are forwarded using the Store and Forward widget from the business space.

To run the sample:

  1. Download Example1.zip that is provided in the samples.zip file. The PI has two modules, AssemblyService and InventoryService, and a library.
  2. Import the sample to Integration Developer.
  3. Create a queue manager with a name of Test_QM. Create a server-connection channel with a name of CHANNEL1, and configure the listener port with port number 1414 in WebSphere MQ. The import connects to the queue manager using client bindings. Create a queue name of inventory_export_queue in Test_QM. You can use the MQ Explorer to perform these activities. Look into the properties of the import and export in Integration Developer. Note that CPUInventoryImport places the requests in the inventory_export_queue where CPUInventoryExport listens. These values are configured on the Import and Export. Set the proper value for J2C authentication data entry in the Security attributes section of Import and Export. For more information about the MQJMS bindings, see the WebSphere MQ JMS topic.
  4. Deploy the sample on the test server.
  5. Test a request flow using the Integration Developer test client. Right-click the AssemblyUnit component click the Test component option. Provide the following input values:
    CPU_item_no:1
    Quantity:5
  6. Check the Systemout.log file for the following output:
    Status=Available
    Available_date=Today
    CPU_details=Intel PENTIUM
  7. Stop the queue manager Test_QM by using MQ Explorer. Send a request as shown below:
    CPU_item_no:2
    Quantity:12
  8. A failed event will be generated as shown in Figure 4. Use the admin console to view the failed events. Notice that the value of the Event qualifier is Initiated store.
    Figure 4. Failed event generated when the queue manager not available
    Failed event generated when the queue manager not available
  9. Send two more requests with the following input values:
    CPU_item_no:3
    Quantity:16 and
    CPU_item_no:3
    Quantity:29
  10. Observe that no more failed events will be generated. However, the requests will be stored in the import queue as shown in Figure 5. Use the Service Integration Bus Explorer in the admin console to view the queue points on the SCA-SYSTEM bus.
    Figure 5. Requests stored in the Import queue
    Requests stored in the Import queue
  11. Launch the business space and create a space with a name of StoreAndForward and add the Store and Forward widget to the space and save it. The widget shows the status as “Storing” as shown in Figure 6. Note the service control points in the widget. There is only one service control point whose name is the same as the one provided for Configuration name on the store-and-forward configuration (see Figure 3). Launch the business space by right clicking on the Server in the server’s view and selecting the option Launch > Business Space in Integration Developer.
    Figure 6. Store and Forward widget in Business Space
    Store and Forward widget in Business Space
  12. Start the queue manager Test_QM. On the Store and Forward widget, select the check box on the store and click the Forward button. This will replay all the stored messages to the queue manager. The CPUInventory service will process the requests. Check the Systemout.log files for output messages. However, the failed event generated initially must be manually submitted through the admin console.
  13. The Store and Forward widget shows the status of the store as “Forwarding” as shown in Figure 7.
    Figure 7. Store and Forward widget showing the status as “Forwarding”
    Store and Forward widget showing the status as “Forwarding”

Scenario 2: Store-and-forward on synchronous imports (WebServices)

In this scenario, the store-and-forward qualifier is configured on an import with Web services bindings. However, the Web service import is called asynchronously. This triggers the message store when the Web service throws runtime errors (when it is unavailable). The message store will be the queue created for the import. The business scenario and the sample application are explained below.

The ABC computer manufacturing company has an assembly division, which requires computer monitors for assembly. The assembly division contacts a vendor for buying computer monitors. This vendor provides a Web service through which customers can submit orders. The order consists of monitor item number and quantity. The response from the Web service is whether the requested order can be served immediately, or when the stock will be available. The assembly diagram shown in Figure 8 provides the details.

Figure 8. Assembly diagram of the Vendor Web service
Assembly diagram of the Vendor Web service

In Figure 8, the ComputerMonitorVendor component is exported using WebService bindings. The AssemblyDivision component places the order through ComputerMonitorVendorImport, which calls the Web service. The order request is an asynchronous request-response with a callback. The store-and-forward qualifier is configured on the ComputerMonitorVendorImport as shown in Figure 9.

Figure 9. Store-and-forward configured on Web service import
Store-and-forward configured on Web service import

There may be issues related to network problems or other problems in the vendor’s environment, which can make the Web service unavailable. Since the store-and-forward qualifier is configured on ComputerMonitorVendorImport and it is called asynchronously from AssemblyDivision component, the orders are stored in the import queue. Only the first order, which fails, generates failed event and subsequent orders will be stored in the import queue. In this way, the Assembly division can continue generating order requests, irrespective of whether the vendor Web service is available or not. When the Web service comes online, the stored orders can be replayed using the Store and Forward widget in the business space. These requests will be processed by the ComputerMonitorVendor component and responses will be pushed to the AssemblyDivision component.

To run the sample:

  1. Download Example2.zip that is provided in the samples.zip file. The PI has two modules, AssemblyService and ComputerMonitorVendorService, and a library.
  2. Import the sample to Integration Developer. Change the port number on the Web service end point to a proper value.
  3. Deploy the sample and test the AssemblyDivision component using the Integration Devloper test client.
  4. Stop the ComputerMonitorVendorService module in Integration Developer and send a request. A failed event will be generated with the event qualifier value as an “Initiated store”.
  5. Send two more order requests. These requests will not generate failed events. The requests are stored in the Web service import queue as shown in Figure 10.
    Figure 10. Order requests stored in the Web service import queue
    Order requests stored in the Web service import queue
  6. Open the Store and Forward widget in the business space and notice that the status of the service control point (ComputerMonitorVendorService_Unavailable) is “Storing”. Refer to Step 11 in Scenario 1 for information about how to open the business space and view the Store and Forward widget.
  7. Start the ComputerMonitorVendorService module and set the status back to “Forward” in the Store and Forward widget.
  8. Resubmit the failed event that was generated initially.
  9. Observe the output messages in the SystemOut.log file.

Scenario 3: Store-and-forward on an SCA export

So far, we have demonstrated the store-and-forward feature on the imports with message bindings and Web service bindings. Similarly, you can configure the store-and-forward qualifier on an SCA export as well (not on other exports). When configured on the SCA export, if the export calls an SCA component synchronously and the component throws a runtime exception, the first failed request will generate a failed event and subsequent requests will be stored in the SCA export queue. Figure 11 shows an example application scenario with a sequence of calls that initiate the store. Note that by default, the preferred interaction style of SCA import or export is synchronous. In order to initiate the store, the preferred interaction style of SCA import or export must be set to “asynchronous”. You can easily simulate this scenario by following the similar steps provided in the previous scenarios.

Figure 11. Store-and-forward qualifier on the SCA export
Store-and-forward qualifier on the SCA export

Step 6 in Figure 11 stores the requests in the export queue.

Scenario 4: Store-and-forward with asynchronous exports (JMS, MQ, MQJMS, generic JMS)

The messaging exports call their corresponding components asynchronously. Therefore, when the store-and-forward qualifier is configured on the component and the component experiences runtime errors, the store is triggered and messages are stored in the component queue. Figure 12 shows an example application scenario with a sequence of steps that initiate the store. You can easily simulate this scenario by following the similar steps provided in the previous scenarios.

Figure 12. Store-and-forward qualifier on the SCA component
Store-and-forward qualifier on the SCA component

Step 4 in Figure12 stores the requests in the component queue.

Scenario 5: Store-and-forward feature with multiple interfaces and references

In this scenario, the store-and-forward qualifier is configured on a SCA component, which calls two services synchronously. The called services are webservices. If one of the called services is down, the component receives a runtime error and generates a failed event. The subsequent requests will be stored in the component queue. Note that even though only one of the services is down, while other service is still available, all the requests to the components are stored. The business scenario and the sample are explained below.

A computer manufacture company requires computer monitors for assembly. It contacts a vendor who supplies the computer monitors. The vendor exposes two services that perform the order processing. The first service is ComputerMonitorVendorService, which accepts orders and returns the information as to whether the item and the requested quantity are available or not. If the item and quantity are available, vendor allows payment through credit card. The payment service is provided by the PaymentGatewayService.

Both services are exposed through Web services. The computer manufacturing company has to first check the availability of the item and quantity using ComputerMonitorVendorService, and then contact PaymentGatewayService to pay the amount. The computer manufacturing company has deployed ComputerMonitorBuyerService, which calls ComputerMonitorVendorService and PaymentGatewayService synchronously in the sequence to place the request orders and to pay the amount if the item and quantity are available. Figure 13 shows the assembly diagram.

Figure 13. Assembly diagram of ComputerMonitorBuyerService
Assembly diagram of ComputerMonitorBuyerService

The store-and-forward qualifier is configured on the ComputerMonitorBuyer component, as shown in Figure 14.

Figure 14. Store-and-forward configuration on the component
Store-and-forward configuration on the component

If one of the services, either ComputerMonitorVendorService or PaymentGatewayService, is unavailable, then all the requests to ComputerMonitorBuyer are stored. When the unavailable service becomes available, the stored requests are replayed on both services in the sequence. For example, if PaymentGatewayService is unavailable, ComputerMonitorBuyer will call ComputerMonitorVendorService to find out whether the stock is available or not for the given order.

However, the call to PaymentGatewayService fails. This generates the failed event and store is initiated. The subsequent order requests will be stored. When PaymentGatewayService becomes available, stored requests will be replayed. The sample contains Test.jsp that you can use to send the order requests to ComputerMonitorBuyer component. Test.jsp calls ComputerMonitorBuyer asynchronously with the order request. The request is a one-way operation.

Store-and-forward with long running business processes

In this example, if ComputerMonitorBuyer is a long running BPEL process, then the store-and-forward configuration will not work. That is, long running processes do not support store-and-forward.

To run the sample:

  1. Download Example3.zip that is provided in the samples.zip file and import it into Integration Developer.
  2. Deploy the modules on to the test server. Modify the port numbers on the Web service end points appropriately.
  3. Access Test.jsp, which is in the WebClient project. Right-click it and select Run as > Run on server. Provide the input values as shown in Figure 15.
    Figure 15. Input values provided through Test.jsp
    Input values provided through Test.jsp
  4. In the SystemOut.logs, observe the following output:
    Inventory status=Available
    Available date=Today
    Computer monitor details=IBM Monitor
    Payment status=PAYMENT DONE
    Payment details=CREDIT CARD ACCEPTED
  5. Stop the PaymentGatewayService module.
  6. Resend the same request as shown in Figure 15.
  7. A failed event will be generated, which initiates the store.
  8. Send another request as shown in Figure 16.
    Figure 16. Input values provided through Test.jsp
    Input values provided through Test.jsp
  9. Send another request as shown in Figure 17.
    Figure 17. Input values provided through Test.jsp
    Input values provided through Test.jsp
  10. Observe that no failed events are generated, but the requests are stored in the component queue, as shown in Figure 18.
    Figure 18. Requests stored in the component queue
    Requests stored in the component queue
  11. Go to the Store and Forward widget and observe that the ComputerMonitorVendorService_Unavailable service control point is in the state of “Storing”.
  12. Start the PaymentGatewayService module and set the status back to "Forwarding" in the Store and Forward widget.
  13. Resubmit the initially created failed event.

Exception specification in the store-and-forward configuration

In this section, the exception specification part of the store-and-forward configuration is discussed. See Configuring the store-and-forward feature for applications for information about exception specifications.

EmployeeServiceComponent calls EmployeeDetailsServiceComponent to retrieve the details of a given employee with the employee number (Empno). The service invocation is a synchronous invocation through the SCA import and SCA export. You can observe the output in the SystemOut.log file. The store-and-forward qualifier is configured on EmployeeServiceComponent. The EmployeeService module is packaged with the custom RuntimeException1 class, which is a subclass of java.lang.RuntimeException.

If Empno is other than {1, 2, 3, 4, 5, 6}, a “RuntimeException1” is thrown in EmployeeDetailsServiceComponent. Test.jsp calls EmployeeServiceComponent asynchronously. We will illustrate how store-and-forward works with the various options in the exception specification. Import Example4.zip that is provided in the samples.zip file into Integration Developer and follow the instructions provided in the following sections.

ServiceRuntimeException on the store-and-forward qualifier

  1. The downloaded application will have the store-and-forward qualifier on EmployeeServiceComponent configured, as shown in Figure 19.
    Figure 19. ServiceRuntimeException specified for store-and-forward
    ServiceRuntimeException specified for store-and-forward
  2. Deploy the application on the test server and invoke the request flow using Test.jsp. Test.jsp is packaged in the EmployeeServiceWebClient project. Right-click the JSP file and select Run as > Run on server. Verify that the request flow works successfully.
  3. Stop the EmployeeDetailsService module and trigger a request. A failed event will be generated and subsequent requests are stored.
  4. Start EmployeeDetailsService and forward the requests using the Store and Forward widget and resubmit the failed event.
  5. After the EmployeeDetailsService module is started, trigger a request through Test.jsp with Empno as 10. EmployeeDetailsService will throw a “RuntimeException1”. RuntimeException1 is wrapped in ServiceRuntimeException, which is configured on the store-and-forward qualifier. Therefore, a failed event is generated and subsequent requests will be stored.

RuntimeException1 on the store-and-forward qualifier

  1. Modify the store-and-forward qualifier with RuntimeException1 as shown in Figure 20.
    Figure 20. RuntimeException1 specified for store-and-forward
    RuntimeException1 specified for store-and-forward
  2. Redeploy the application with the above modification and test a request flow using Test.jsp successfully. Stop the EmployeeDetailsService module and trigger a request flow. A failed event will be generated, but it will not trigger the store. This is because RuntimeException1 is configured for the store-and-forward qualifier. However, the unavailability of EmployeeDetailsService throws a ServiceRuntimeException, which is not configured for store-and-forward.
  3. Start the EmployeeDetailsService module and resubmit the failed event.
  4. Trigger a request with Empno as 11. This will make EmployeeDetailsServiceComponent throw a RuntimeException1 and a failed event will be generated and the store is triggered.

RuntimeException1 on the store-and-forward qualifier with exception message

  1. Modify the store-and-forward qualifier as shown in Figure 21.
    Figure 21. Exception and exception message on store-and-forward
    Exception and exception message on store-and-forward
  2. Note the “Message to match” property. It has been provided a value of “This is RuntimeException1”, which is actually the message text that RuntimeException1 contains when it is thrown in EmployeeDetailsServiceComponent.
  3. Deploy the application and trigger a request using Test.jsp. Test whether the request runs successfully. Trigger a request with Empno as 11. This will generate a failed event and the store is triggered. This is because both the exception and the exception message match.
  4. Modify the “Message to match” property as RuntimeException1 Message. Redeploy the application and trigger a request with Empno as 11. A failed event will be generated, but it will not trigger the store because the exception message does not match what is specified on the store-and-forward qualifier.

Scenario 4: Exception chain configuration on store-and-forward qualifier

  1. Modify the store-and-forward qualifier on EmployeeServiceComponent as shown in Figure 22.
    Figure 22. Exception chain configuration on store-and-forward
    Exception chain configuration on store-and-forward
  2. Notice the value of the Exception chain. It has been set to “Match only the top level exception”. The exception remains RuntimeException1.
  3. Trigger a request flow with Empno as 11. This will make EmployeeServiceComponent throw a RuntimeException1. But, RuntimeException1 is wrapped in the top level exception ServiceRuntimeException, as shown in Figure 23. Since the store-and-forward configuration is set to match only the top level exception, a failed event is generated, but the store is not triggered. Similarly, you can test the other exception chain values. You can also test match types that inherit from this type of option with a simple application.
    Figure 23. Exception stack trace in the failed event
    Exception stack trace in the failed event

Conclusion

The tutorial described how to configure the store-and-forward qualifier on various components, such as the import, export, and SCA component. Sample applications showed how store-and-forward works and where the message store is triggered. It provided information about how to relay the stored messages using business space widgets. It also illustrated how exceptions trigger the store with a comprehensive sample application. The store-and-forward is a useful feature that helps applications regulate the flow of application requests when services are available or unavailable.


Download

DescriptionNameSize
Code samplessamples.zip643KB

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

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

 


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

All information submitted is secure.

Choose your display name



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

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

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

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

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=495864
ArticleTitle=Using the store-and-forward feature in WebSphere Process Server V7.0
publish-date=06162010