Examining and editing the results after running the Service Wizard
The Service Wizard forms show required fields only. To specify values for optional settings or to modify values after the rules and data objects are saved, open the individual rule or data object and make the changes in that form. For example, to configure a response queue for a JMS or MQ service, you need to edit the generated service rule.
You can open generated rules and data objects from the confirmation page that is displayed when the Service Wizard finishes. Or you can navigate to individual items by using the Find function, the Class Explorer, or the Rules by Type explorer.
Service rules for all types
When the Service Wizard displays the Review And Save form, you can see information about all the service rules and the service package that you are generating. The following table provides default field values that are assigned to the generated service rules.
Field | Value |
|---|---|
Service package | The name of the service package that you selected or created. You cannot change the name of the service package. |
| Processing mode | Select Stateful to maintain a clipboard for subsequent service requests. Select Stateless to perform a simple calculation from inputs: the service request arrives, your activity performs a calculation, and then sends the response. |
| End requestor when done | For stateful services, select the End requestor when done check box only on the last service of a series of requests. This indicates that you are finished with the requestor and it can be destroyed. Earlier requests in the series have the box cleared, so that the same requestor is used throughout. The End requestor when done check box has no effect on stateless services. Regardless of the check box setting, when a service has completed, the requestor is not destroyed so that the Process Commander can reuse it for subsequent service requests. |
Service class | If the service creates a work item or performs an action on one, the service class is set to the name of the work class that you selected to identify the flow or the flow action. |
Service method | The name of the specified flow, the name of the specified flow action, or the name of the selected activity. |
Primary page class | If the service creates a work object or performs a flow action, the primary page class is the work class (that is, the class that the flow applies to). If the service calls an activity, the primary page class is the class that the activity applies to. |
Primary page model | If the service rule creates a work object, the primary page model is pyDefault, the model used to instantiate new work objects. In this case, do not change the value of this field. Process Commander uses the values from this field and the Primary Page Name field to initialize the primary page prior to calling the service activity. |
Primary page name | If the service rule creates a new work object, the name of the primary page is pyWorkPage, which is the primary page for a work object. Process Commander uses this value and the value of the Primary Page Model file to initialize the primary page prior to calling the service activity. |
Service activity | If the service rule creates a work object, the service activity is svcAddWorkObject. |
Final activity | The service activity for a file service is called the final activity. File service rules only. |
XML Schema File | The XML schema that the Accelerator generates when you select Use XML for Mapping Data. |
Examine the data mappings that are configured on the Request and Response tabs to verify that they reflect the purpose of the service and to modify them if they do not.
MQ services
The Service Wizard does not display the fields from the MQ listener form that you use to configure transacted messaging for MQ services. To configure transacted MQ messaging, open the listener record and specify values in the appropriate fields. For more information, see How to build an MQ Listener that supports Transacted Messaging.
By default, Process Commander uses the queue that is specified in the incoming message as the response queue for an MQ listener. If you want to change this value, specifying a different queue for the response, see How to Specify a Response Queue for an MQ Listener.
JMS services
By default, Process Commander uses the queue that is specified in the incoming message as the response queue for a JMS listener. If you want to change this value, specifying a different queue for the response, see How to Specify a Response Queue for a JMS Listener.
If you are using a message-driven bean (MDB) as the JMS listener, you must open the listener object and generate a deployment descriptor fragment. See How to deploy a JMS listener as a message-driven bean (MDB) in v 5.4.
Requestor pooling
The service package provides default values for requestor pools. To fine-tune the requestor pool, open the individual service package instance and make your changes.
You specify how many requestors can be in the pool on the Pooling tab of the Service Package form. The setting for the number of idle requestors defines the size of the pool. The setting for the number of active requestors defines how many concurrent requestors you want to allocate to the services in the service package.
Previous topic Before you run the Service Wizard Next topic Configuring a service to process requests asynchronously