This topic explains how to configure and apply the webMethods tool, which allows you to publish and send BrokerEvent objects to Software AG webMethods Broker, as well as subscribe to events and invoke native webMethods IS (Integration Server) services. Sections include:

Working with Broker

The configuration steps vary according to the execution mode you want to use (publish, subscribe, request/reply). 

Adding Required Jar Files to the Classpath 

The following .jar files always need to be added to the SOAtest classpath:

The .jar files can be found under <WEBMETHODS_INSTALL_DIR>/common/lib/. For more details, please refer to webMethods Broker Client Java API Programmer's Guide > Getting Started > Using the webMethods Broker Java API.

In some cases, the enttoolkit.jar found under <WEBMETHODS_INSTALL_DIR>/common/lib/ext is also required.

To add these jar files to SOAtest classpath, complete the following:

  1. Go to Parasoft > Preferences.
  2. Open the Parasoft > System Properties page.
  3. Click Add JARS and choose and select the necessary .jar files to be added.

Using Publish Execution Mode

To configure the webMethods tool to publish BrokerEvent objects:

  1. Open up the tool configuration panel.
  2. Open the Tool Settings tab.
  3. Specify tool settings as follows:
    1. From webMethods, select Broker.
    2. From Execution mode, select Publish.
    3. In the Host, Broker Name, Client Group, and Client ID fields, specify the settings for connecting to Broker.
    4. In the AppName field, enter any name that you want to use to identify the application (SOAtest).
    5. Click Refresh. The Event Type menu will then be populated with the available event types on the broker.

    6. (Optional) In Subscription Filter, specify a filter string in order to retrieve only the events with desired field values. For example, you may use expressions such as
      my_Strin_field="some value" and my_int_value < 5
      For more details on the syntax of filter strings, see the WebMethods Broker Client Java API Programmer's Guide, "Using Event Filters" section.

    7. In Event Type, select the event type to which you want to publish.
    8. In the Timeout area, customize the timeout period and timeout conditions if desired.
      • If the Pass the test only if timeout occurred option is enabled, the tool will fail if a Broker Event is received at the specified event type. This is typically useful for subscribing to error event types and ensuring that no error event types are published as part of a test scenario.
  4. Open the Inputs tab.
  5. Use the available controls to specify what BrokerEvent object you want published.

During test execution, SOAtest publishes the event by invoking the broker client Java API and providing it with a BrokerEventobject. Any applications that are subscribed to that event type will receive the event that SOAtest published. 

To view an XML representation of the events that are published, use the Traffic Viewer tool, which is automatically chained to the webMethods tool. Note that even though actual BrokerEvent objects are sent and received, the viewer uses an XML representation. This makes it easier to read and allows you to chain tools that validate or process the content (for example, the Diff tool or XML Assertor tool). 

Using Subscribe Execution Mode

To configure the webMethods tool to subscribe to BrokerEvent objects:

  1. Double-click the webMethods Test Case Explorer node to open up the tool configuration panel.
  2. Open the Tool Settings tab.
  3. Specify tool settings as follows:
    1. From webMethods, select Broker.
    2. From Execution mode, select Subscribe.
    3. In the Host, Broker Name, Client Group, and Client ID fields, specify the settings for connecting to Broker.
    4. In the AppName field, enter any name that you want to use to identify the application (SOAtest).
    5. Click Refresh. The Event Type menu will then be populated with the available event types on the broker.
    6. In Event Type, select the event type to which you want to subscribe.


During test execution, SOAtest starts listening for events that are published to the specified event type. 

To view an XML representation of the events that are received, use the Traffic Viewer tool, which is automatically chained to the webMethods tool. Note that even though actual BrokerEvent event objects are sent and received, the viewer uses an XML representation. This makes it easier to read and allows you to chain tools that validate or process the content (for example, the Diff tool or XML Assertor tool). 

Using Request/Reply Execution Mode

To configure the webMethods tool to send a BrokerEvent object and wait for a reply before sending another:

  1. Double-click the webMethods Test Case Explorer node to open up the tool configuration panel.
  2. Open the Tool Settings tab.
  3. Specify tool settings as follows:
    1. From webMethods, select Broker.
    2. From Execution mode, select Request/Reply.
    3. In the Host, Broker Name, Client Group, and Client ID fields, specify the settings for connecting to Broker.
    4. In the AppName field, enter any name that you want to use to identify the application (SOAtest).
    5. Click Refresh. The Event Type menu will then be populated with the available event types on the broker.
    6. In Event Type, select the event type to which you want to send.
  4. Open the Inputs tab.
  5. Use the available controls to specify what BrokerEvent object you want sent.

During test execution, SOAtest sends a request by invoking the broker client Java API and providing it with a broker event object, then it waits for a reply. 

To view an XML representation of the request and reply events, use the Traffic Viewer tool, which is automatically chained to the webMethods tool. Note that even though actual BrokerEvent objects are sent and received, the viewer uses an XML representation. This makes it easier to read and allows you to chain tools that validate or process the content (for example, the Diff tool or XML Assertor tool). 

Specifying Scripted Inputs

When publishing to a Broker or doing a request/reply using scripted input, two arguments will be passed into your custom method. The first argument is a BrokerEvent object for the type name you specified in the tool settings. You need to populate this object with the desired input values (see the webMethods Broker Client Java API Programmer’s Guide for details on how to accomplish this) then return it. The second argument is a test tool com.parasoft.api.Context object. 

Here is a sample Jython script:

from com.parasoft.api import *
from COM.activesw.api.client import *
 
def configureBrokerEvent(event, context):
    event.setUCStringField("s", "something")
    event.setIntegerField("i", 1)
    event.setUCStringSeqField("sl", 0, BrokerEvent.ENTIRE_SEQUENCE, BrokerEvent.AUTO_SIZE, ["one", "two", "three"])
    return event

Working with Integration Server

Adding Required Jar Files to the Classpath

The following .jar file needs to be added to the SOAtest classpath:

It can be found under <WEBMETHODS_INSTALL_DIR>/common/lib/. In some cases, the enttoolkit.jar found under <WEBMETHODS_INSTALL_DIR>/common/lib/ext/ is also required. To add a .jar file to SOAtest classpath, complete the following:

  1. Go to Parasoft > Preferences.
  2. Open the Parasoft> System Properties page.
  3. Click Add JARS and choose and select the necessary .jar file to be added.

Using SOAtest with Integration Server

To configure SOAtest to invoke webMethods IS (Integration Server) services and receive responses:

  1. Double-click the webMethods Test Case Explorer node to open up the tool configuration panel.
  2. Open the Tool Settings tab.
  3. Specify tool settings as follows:
    1. From webMethods, select Integration Server.
    2. In the Host, User, and Password fields, specify the settings for connecting to Integration Server.
    3. Click Refresh. The Package menu will then be populated with the packages available on Integration Server.
    4. In Package, choose the package that contains the service that you want to invoke.
    5. In Service, select the service that you want to invoke.
  4. Open the Input tab.
  5. Use the available controls to specify what iData object will be used to invoke that service.

During test execution, SOAtest sends iData objects to invoke Integration Server services and receives responses.

To view an XML representation of the objects that are sent and received, use the Traffic Viewer tool, which is automatically chained to the webMethods tool. This XML representation uses the iData XML coder format. Note that even though actual iData objects are sent and received, the viewer uses an XML representation. This makes it easier to read and allows you to chain tools that validate or process the content (e.g., the Diff tool or XML Assertor tool). 


Specifying Scripted Inputs

When using an Integration Server service with scripted input, your custom method will be passed two arguments. The first is an IData object that you need to populate with the desired data and then return. The second argument is a com.parasoft.api.Context object. 

Here is a sample Jython script: 

from com.wm.app.b2b.client import * 
from com.wm.data import *
 
def buildIData(idata, context):
    IDataUtil.put(idata.getCursor(), "in1", "12")     
	IDataUtil.put(idata.getCursor(), "in2", "13")     
	return idata

Accessing the Session ID

The session ID is automatically saved to the WebMethodsSessionId context variable. It can be accessed from an Extension tool, script, or custom tool using com.parasoft.api.Context.get(String key), where String key is  "WebMethodsSessionId".

For example, the following Extension tool (using a Groovy script) accesses the session id that is stored in the sessionId variable,:

import com.parasoft.api.*
boolean useSessionId(input, context) {
    sessionId = context.get("WebMethodsSessionId")     
	Application.showMessage("sessionId = " + sessionId)
    // Put code here to do something with the session id    
	return true
}