Service Requests

The Service Requests (CSRVREQ) page allows you to search for service requests using various criteria, such as request received date range, web service name, message name, listener name, processing outcome, and so forth. The Service Request Detail page shows details such as date/time when a request was received, web service name, operation name, the orchestration service name that processed the request, processing outcome, request payload, service response, and service response payload.

This page does not allow any modifications to any service request or service response. Using the row-level menu, you can navigate to the corresponding Log Entry page to view any log entries for a service request. In addition, you can also navigate to the ER Delivery Status page to view any ER Delivery Status for a service request.

Note: The text on the confirmation modal for the Authorize Request and Reject Request actions can be configured from the CTEXT page with codes CREQAUTH and CREQRJCT, respectively.

The following tables provide descriptions of various Service Request fields:

Service Request Fields

Field

Description

Service Request Number

A unique number for a Service Request. It is internally generated by Connect.

Correlation Id

An identifier that can be included by client applications when submitting a request to Connect. It is used for easier tracing of service requests across multiple systems.

Source Application

It identifies the source application that sent a service request.

Processing Pattern

For web services, it is either Request Response or One Way.

For events/messages, it is Sequential or Asynchronous.

Processing Status

Valid values are:

  • Received: Gateway IN has received request.

  • Routed: Request has been passed to Orchestration module.

  • Processed: Request has been processed.

  • Timeout: Gateway IN timed out while waiting for response (applicable in case of Request/Response and Sequential processing patterns).

Processing Outcome

Valid values are:

  • Success: service request processing passed.

  • Failure: service request processing failed.

  • Partial-Failure: service request was processed but with some failures.

Web Service

Indicates the Web Service Name. Applicable if Service Request represents a Web Service call.

Web Service Operation

Indicates the Web Service Operation Name. Applicable if Service Request represents a Web Service call.

Message Name

Indicates the Message Name. Applicable if service request represents a message or an internal event.

Key Values

Every WS Operation and Message Name in Connect has associated Key Tags (or Key Field Names). This field represents concatenated Key values for the service request.

Format

Indicates the format of service request payload.

  • For messages, it is JSON.

  • For web services, it is usually JSON or application.

  • For files, it is usually XML.

Listener

External Listener over which the service request was received. Applicable to Non-Rest API related service requests.

Request Received Timestamp

Exact date/time when a service request was received by Connect in the local time zone.

Gateway IN Module Name

Gateway IN module name that received the service request.

Gateway IN Module Instance

Gateway IN module instance Id that received the service request.

Orchestration Module

Orchestration module name that processed the service request.

Orchestration Service name

Orchestration Service name that processed the service request. If a file-based service request is processed by an OS Route then this field will be displayed blank.

Orchestration Service template

Orchestration Service template associated with Orchestration Service name. If a file-based service request is processed by an OS Route then this field will be displayed blank.

Message Order Group Hash

Gateway IN uses configured Key Tag/Field Names for message grouping purposes. This field represents a hash/mod of the key values. Used only for internal purposes.

Request Payload

Original payload (typically JSON) for the service request.

Custom Fields

This is where the client specific implementations add custom fields to FPC (File Processing Configurations). Example: Record Count, Total Amount, and so forth.

Service Response Fields

Field

Description

Service Response Number

A unique number generated by Connect for every service response.

Receive Instance id

The Gateway IN Module Instance that received the service response.

For Request/Response and Sequential processing patterns, it will be the same as the Gateway IN Module Instance field value. However, in case of one way / asynchronous processing patterns or timeout scenario, a different module instance may receive the service response.

Processing Status

Processing Status associated with the Service Response. It could be either Failure or Success.

Received Timestamp

Date/Time when the Gateway IN module received the service response.

Generated Timestamp

Date/Time when the service response was generated.

Response Payload

This indicates the Service Response payload.

File Processing and OS Route Fields

Field

Description

OS Route Name

Orchestration Service Route that processed the service request.

Note that a file-based service request may be processed by a single Orchestration Service or by an OS Route that has more than one Orchestration Service.

FPC ID

An interface file may be received by Connect via any of the file based External Listeners. Processing rules of a file are configured using FPC (File Processing Configurations (CFPCAPP) page). This field indicates the FPC ID that was used to process this service request.

Note: Every FPC record contains a Regex field. When a file is received by Connect, the input file name is matched against the configured FPC IDs’ Regex field to determine the FPC ID that should be used to process the input file.

FPC Alternate ID

Every FPC ID also has an Alternate ID that can be used for searching service requests. This field indicates the FPC Alternate ID corresponding to the FPC ID that can be used to process this service request.

FPC Additional Configuration

FPC Additional Configuration is a JSON format that has various file processing related configurations such as Custom Validation class, SMU Job Parameters, Pre-Authorized Actian (PDI) configuration, and so forth. This additional configuration is saved, along with the service request, to keep a record of additional configuration used for processing a file-based service request. Refer to the “File Processing Configurations” section for more details on this JSON format.

File Name

Name of the input file that contains interface data. Note that Connect does not look into the contents of an interface file.

Waiting for Authorization

For file-based service requests, FPC Additional configuration indicates if the file is pre-authorized or needs authorization before submitting the file to the SMU Job. If the file needs manual authorization, then Connect Authorization Check will set this flag to True. This also allows searching for service requests that are waiting to be authorized easier.

Authorized By

This field indicates the User ID that authorized the service request. In case of Pre-Authorized, this field is set to “Connect Auto”.

Authorized Timestamp

This field indicates the date/time when this service request was authorized.

Service Request Route Steps Fields

This tab provides the route steps for the OS Route that was used to process the service request. If an OS Route was not used to process a service request then this tab’s field values will be displayed blank.

Field

Description

Route Step Number

This field indicates the route step number.

Processing Status

This field indicates the processing status of the route step.

  • SUCCESS – Indicates that the route step has been processed successfully.

  • FAILURE – Indicates that the route step failed. In case of failure, a Log Entry is submitted to the CEH Server with the full details of the error (Log Entry (CLOGENT) page).

  • STOPPED_BEFORE_EXEC – Indicates that the route processing was stopped before executing this step. This is applicable to the route steps that can be executed only after an event indicates that this step can be executed. For example, the Authorization Check Completed step can only be executed after the authorization has been provided, if manual authorization. Another example: The SMU Job Completed step can be executed only after the corresponding SMU Job has completed.

  • Blank – Indicates that the Service Request processing using OS Route has not reached this step yet.

OS Name

Indicates the OS Name corresponding to the OS Route Step.

Request Payload

Indicates the Request payload that was sent to the OS Name to process this step.

Response Payload

Indicates the Response payload from OS Name that processed this step.