Integration Q

Integration Q

SETUP A SOAP SERVICE

The Service Wizard walks us through the process of gathering the details of the service to be created.

In the first screen the wizard asks us about the purpose of the service. A service always requires an activity, which provides the logic for the service. The service purpose defines the activity. There are three options:

• Create and manage work
• Invoke existing activity rule
• Process input and output data

Choose Create and manage work to use the service to create a new case and perform one or more processing action(s) upon it. When selecting this option, the wizard generates two activities for use by the service. 

• svcAddWorkObject, which creates the case and starts the specified flow. This is the standard service activity for services that create new cases.
• svcPerformFlowAction, which identifies the case and then calls the specified flow action. This is the standard service activity for services that perform a flow action on a case.

Select Invoke existing activity rules to use an existing activity to manipulate an existing case.

Select Process input and output data to map data to or from the clipboard, such as to update the contents of a data table. The wizard creates the service rule and a new empty activity. This activity can be configured to use the mapped input data to perform an action, and to populate the clipboard properties to be returned in the mapped output fields.

We need to select ruleset and service package.

Typically we want to create the service rules in the application ruleset. The service package defines the deployment of the service. A service package typically represents a WSDL and all services belonging to the service package will show up as operations in the WSDL.

It is a best practice to have a dedicated access group for services, which has minimum privileges required to run the service activities. If our application has services that have individual security policies, we may have multiple service packages and access groups.

Select Requires Authentication to authenticate the service client at runtime. If this option is selected the client needs to provide a valid operator and password when calling the service

If the check-out feature is used we need to ensure that all rules related to the service is checked in before using the deployment tab since rules in private rulesets are ignored.

We can use the Run in the Actions menu on the service rule to test our service. Select Run and we get a pop-up that allows us to enter various input parameters.

1. Our initial test should use the “Use current requestor context” option to test the service activity and mapping rules.When using the current requestor context some processing steps are not attempted:
1. Lookup Service Properties
2. Initialize Requestor
3. Perform Authentication
2. In order to fully test our service, we want to include the above.  Select “Initialize service requester context”
3. The final test is to invoke the service from an external application.

SETUP A FILE LISTENER

The service file rules support three types of parse rules:

• Parse XML rules which are used for XML files.
• Parse Delimited rules which are used when a comma, tab, quote, or other character separates fields within each input record.
• Parse Structured rules which are used to import fixed-format flat files

The Method tab describes how the system detects fields and records in the input files.

There are three options for the processing method:

• File at a time parses the entire file.
• Record at a time parses a record at a time. Use the Record Terminator or Record Length fields to identify the record.
• By record type extracts a record type from the record. Use the Offset and Length fields to identify the record type and the Record Terminator or Record Length to identify the record.

Process tab

It is possible to specify an Initial Activity that is run before processing each input file and a Final activity that is run after the entire file is processed.

How the information configured in the Parse Segments is used depends on the processing method specified in the Methods tab.

• The Record Type is used to identify which parse segment to apply to a record parsed from the file. This option is only relevant if the processing method on the method tab is record type.
• Select Once to apply the parse segment only once. This option is useful for files that contain a header record.
• The Map To field defines the action to take in the parse step. The following options are available:
  • Clipboard – Map this segment to a Clipboard property
  • XML ParseRule – Parse the segment with a parse XML rule
  • Delimited ParseRule – Parse the segment with a parse delimited rule
  • Structure ParseRule – Parse the segment with a parse structured rule
  • Skip – Skip this segment
• In our case we want to use a parse delimited rule. Enter the corresponding key for the Map To field in the Map to Key field. In this case it is the name of the delimited rule we want to use.
• If Auth? is selected the system uses two parameters pyServiceUser and pyServicePassword from the parameter page as authentication credentials for a requestor. These two parameters can be set in earlier rows in the parse segments.
• Use the Activity field to specify an activity to run after the data is processed by this parse segment. We want to update the supplier after each record in the file so we specify our service activity here.
• Select Keep Page? to cause the primary page of the activity to be retained after processing of this row is complete. Clear to cause the primary page to be reinitialized after this row is processed.

The Frequency field allows us to specify a number of records to process before committing database changes. When this field is not blank, a final commit operation also occurs after all records are processed. If this field is blank, no automatic commit operations are performed. In our case we want to commit after every record so we set the frequency to 1.

Use the Success Criteria to specify a when rule to be evaluated after each record is processed. If this rule evaluates to false a database rollback occurs backing out of the most recent commit operation and the processing of the file is abandoned.

File Listener

Properties tab

The Startup Option allows us to control how listeners start:

• Run on all nodes – The listener is run on all nodes, in other words all servers in a cluster.
• Node based startup – The listener is started only on specified nodes.
• Host based startup – The listener is started on specified number of nodes on specific servers within the cluster.

The Source Location and Source Name Mask are populated from the wizard. The listener creates three sub-directories within the source directory:

• Work – Original files are copied to the Work directory for recovery attempts
• Completed – Files for which processing completed successfully are copied here
• Report – Report files are copied here

The Concurrent Threads field allows us to specify the number of threads per server node this listener requestor creates when it starts. Each thread operates on a single file, in other words multiple concurrent threads have no benefit unless multiple files are available at the same time for processing.

Process tab

The File Operation field lets us decide what we want to happen to the file if it is successfully processed. It can either be kept or deleted. Choosing keep moves it to the completed folder.

Error tab

If we select Attempt recovery? the system leaves the files containing errors in the Work folder for recovery purposes.
Max Recovery Attempts defines the maximum number of times the system attempts recovery.

In the Cleanup section we can define what we want to happen to the file when an error occurs. It can either be deleted or renamed. If you choose to have it renamed the file extension is renamed to the specified value. The file name itself remains the same.