Hitachi

uCosminexus Service Platform Setup and Operation Guide


7.7.19 Troubleshooting when there is a mistake in user message

Organization of this subsection

(1) Error when there is a mistake in user message

When directly invoking service components of service adapter from standard reception, you must create the user message (XML document) that requests service components in service requester. Thus, if there is a mistake in the XML created in service requester, system cannot invoke the correct service component. The following figure shows the relationship between the SOAP message in SOAP communication and user message.

Figure 7‒135:  Relationship between SOAP message in SOAP and user message

[Figure]

When there is a mistake in user message (when you execute a message in a format which is different than the format of format definition), the error contents will differ depending on the difference in the protocol of service adapter.

Note that depending on the format of the message, there may be instances wherein, instead of an error in service adapter, there may be an exception in service component; or instead of an error in service component, an unexpected response may be returned.

(a) For an error due to wrong user message when executing Web service (SOAP reception)

The specifications of service components that can be called from SOAP adapter must meet the application scope which is given in "2.6.1 Applicability of the service components that use Web service" in "Service Platform Basic Development Guide". Operation of service components which are out of the application scope cannot be guaranteed.

(b) For an error due to wrong user message when executing SessionBean

The specifications of service components which can be invoked from SessionBean adapter, must meet the application scope, indicated in"2.6.2 Application Scopes of Service Components That Use SessionBean" in "Service Platform Basic Development Guide". Operation of service components which are out of the application scope cannot be guaranteed.

(c) For an error due to wrong user message when executing MDB (WS-R/DB queue)

There is no error in the service adapter of MDB (WS-R/DB queue), in case of an error in the user message which is requested from service requester. Schema is defined at the time of defining in the development environment, but normally, even the messages that are not in the format defined in this schema are sent to the asynchronous queue. If you create such that the user message is received and validated in service component, error is detected in service component.

(2) How to validate messages in service adapter

You can validate if the user message (XML document) and format definition (XML schema) which is specified in service adapter are according to the specifications of XML schema.

Set the telegram-validation property in HCSC server runtime definition file for using the service adapter message validation function. For details about the HCSC server runtime definition file, see "6.5.6 HCSC server runtime definition file" in "Service Platform Reference Guide".

Important note

When a message which is invalid as per the defined format definition but successfully invokes service components; if the message format is determined to be invalid by using message validation function, there will be an error in service adapter.

The following table shows the service adapters of the entire HCSC server, where message validation function will be valid. You cannot set the function for each service adapter. Also, the function will be effective for the request messages which invoke service components and for response messages.

Table 7‒178:  Service adapters in which message validation function is effective

Adapter type

Direction

Data transformation definition pattern

Format definition to be validated

Message type

Effectiveness of validation function

SOAP adapter,

SessionBean adapter,

MDB (WS-R) adapter,

MDB (DB queue) adapter

Request

No data transformation

Service component message

XML

Y

Binary

N #1

Standard - service components Data transformation

Standard message

XML

Y

Binary

N #1

Service component message

XML

Y

Binary

N #1

Response

No data transformation

Service component message

XML

Y

Binary

N #1

Service component - Standard data transformation

Standard message

XML

Y

Binary

N #1

Service component message

XML

Y

Binary

N #1

Fault

No data transformation

N

XML

N

DB adapter

Request

No data transformation

Service component message

XML

N #2

Standard - service components Data transformation

Standard message

XML

N

Binary

N

Service component message

XML

N#2

Response

No data transformation

Service component message

XML

N#2

Service component - Standard data transformation

Standard message

XML

N

Binary

N

Service component message

XML

N#2

TP1 adapter

Request

No data transformation

Service component message

Binary

N#1

Standard - service components Data transformation

Standard message

XML

Y

Binary

N#1

Service component message

Binary

N#1

Response

No data transformation

Service component message

Binary

N#1

Service component - Standard data transformation

Standard message

XML

Y

Binary

N#1

Service component message

Binary

N#1

File adapter

Request

No data transformation

Service component message

XML

Y

Binary

N#1

Standard - service components Data transformation

Standard message

XML

Y

Binary

N#1

Service component message

XML

Y

Binary

N#1

Response

No data transformation

Service component message

XML

Y

Binary

N#1

Service component - Standard data transformation

Standard message

XML

Y

Binary

N#1

Service component message

XML

Y

Binary

N#1

Object Access adapter

Request

No data transformation

Service component message

XML

Y

Standard - service components Data transformation

Standard message

XML

Y

Binary

N#1

Service component message

XML

Y

Response

No data transformation

Service component message

XML

Y

Service component - Standard data transformation

Standard message

XML

Y

Binary

N#1

Service component message

XML

Y

Legend:

Y: Validation function is effective.

N: Validation function is not effective.

Request: Indicates that a message is directed from service adapter to service components.

Response: Indicates that a message is directed from service components to service adapter.

Fault: Indicates that a message is directed from service component to service adapter when there is an error.

Note #1

On the basis of set format definition, transformation to DOM (path processing) is performed when invoking service components of binary message. Therefore, if you send a binary message, which is invalid as per the format definition, an exception occurs and the following message is displayed:

KDEC05504-E an attempt to specify format definition settings has failed. (Information1 = maintenance information, information2 = maintenance information)

The settings of format definition failed.

Note #2

DB adapter validates message format with functions other than telegram-validation property. For example, at the time of request when you convert "Requester (binary) - Standard (XML) - Service components (binary)" in service adapter, DB adapter converts and validates request message in the following flow:

  1. Validate request message as per requester format definition (Same when binary message function is OFF).

  2. If the result of validation performed in Step 1 is valid, convert message from requester message format to standard message format.

  3. After conversion, validate the standard message format as per the format definition of standard message.

  4. If the result of validation performed in Step 3 is valid, convert message from standard message format to service component message format.

  5. Validate the converted message as per the format definition of service component (same even when binary message function is OFF).

  6. If the result of the validation performed in Step 5 is valid, then invoke service component.

(3) Analyze by collecting user message trace

Based on the collected user message trace, you can check if the message is flowing as per the design, at the requester side and service side and you can also check the message at all points such as business process activity and data transformation.

For collecting user message trace, perform settings in the following properties of HCSC server runtime definition file:

Also, you can use the following properties to set an HCSC component for which user message traces are to be output during normal processing. With the traces that are output, you can check the messages that are sent to, or received from, requesters or services.

For details about the HCSC server runtime definition file, see "6.5.6 HCSC server runtime definition file" in "Service Platform Reference Guide".

For details about user message trace, see "7.4.4 User message trace" or "7.4.6 Debug information".

Important note
  • There are security issues (concerns like information leaks) for outputting user message contents to a file. Handle user message trace files with special care.

  • You cannot collect user message trace for collection position SVC and collection position CNVST, in the DB adapter which is created by using the "<Installation directory of Service Platform>>\CSC\lib\cscdba.ear" prior to 01-60.