Skip to content

Troubleshooting

Possibilities for tracing and debugging can be very important when trying to find the reason for problems like the examples below:

  • The message is not sent to the customer's web service
  • Incoming messages are not received by IFS Cloud
  • Event is not sent by mail

Note: When debug is activated the performance will be slower. Do not have it activated during normal operation.

Overview of the IFS Connect debug concept

It is recommend to read about the IFS Connect overview before you start to use the debug concept.

  1. Ability to debug all message executions that occur in the IFS Connect JEE application.
    Example of message executions:
  2. A message is read by Connect Reader and is stored to a message queue
  3. Batch Processor starts to execute a message located on queue.
  4. Ability to debug the Connect Readers. For example the file reader which polls a directory for files.
  5. The message traffic to/from the SOAP Gateway can be traced.

Where to find Error messages

On Application Messages

If message located on a queue has failed or is in retry mode the error will be shown like below:

Logging and Debugging of IFS Connect

IFS Connect code is using the new logging framework for logging and debugging. The amount of logged information is controlled by the level of categories 'integration' and 'batchprocessor' (for the core IFS Connect parts) and 'gateway' (for SOAP Gateway).

There is a Solution Manager page under Integration, IFS Connect, JSF Properties, Logging Properties for the user to enable and modify logging properties.


Logger

Logger serves as objects where the application writes its logging and debugging statements. They consolidate this output in a shared memory location.

Handler

Handler can be thought of as the destination for all the logging output generated by an application. Within the IFS connect logging framework, two primary types of Handlers are currently defined:

  • Console Handler(console): This handler prints its output to the console window, typically can be captured by the actual application server. It's a convenient choice for real-time monitoring of log data.
  • File Handler: The file handler writes the output to a file, creating a log file that captures the logged information. This is valuable for historical record-keeping and in-depth analysis. For instance, Text handler(textfile) writes its output as plain text.

Level

There are five levels of logging, each serving a specific purpose:

  1. error: This level is typically used to log serious problems that can potentially lead to application failures.

  2. warning: Use this level for logging warnings in the system. Warnings are meant to capture issues that might not be critical but should be reviewed.

  3. info: This level is used for logging messages of informational character. It provides insights into the normal operation of the application.

  4. trace: Used for examining the system's behavior in detail and for performing light-level debugging. It provides a more granular view of what's happening within the application.

  5. debug: This level is dedicated to logging all the debug statements in the application code. It is specially useful during development and troubleshooting.

Category

In the context of logging, a category defines a specific part or area of an application or a particular type of event that you intend to log. In this system, there are eleven predefined categories:

  1. database: Used for logging database calls,providing insights into interactions with the database.

  2. application: Dedicated for general-purpose logging within the application code.

  3. framework: General-purpose logging originating from the IFS Foundation 1 framework code.

  4. gateway: Specifically for logging events from the code of Client and SOAP Gateways, helping to monitor gateway-related actions.

  5. integration: Used for logging different parts of the Integration area, making it possible to track integration-related operations.

  6. batchprocessor: Tailored for logging within the Batch Processor framework, enabling insights into batch processing activities.

  7. callsequence: Meant for tracing the call sequence of methods, aiding in understanding the order of method execution.

  8. request: Intended for tracing client requests, offering a closer look at incoming requests to the application.

  9. response: Designed for tracing the response sent back to the client, allowing for monitoring the responses.

  10. security: Dedicated exclusively to security-related logging events, providing a detailed record of security-related actions and events.

  11. timings: This category is used for timing measurements of requests, helping to assess and optimize request processing times.

Logging Level Definitions

It is possible to define a global logging level for the entire system, and this definition can be overridden per category. However, a category-specific logging level that is less detailed than the global definition is not possible. For instance, if the global level is set to 'warning', a category-specific level can be set to 'info', but 'error' is not permitted. Such an incorrect definition will not generate an error but will be disregarded.

Level definitions in the configuration file can take one of two forms:

  • global.level=<level>
  • <category>.level=<level>

Here, <category> is one of the defined categories, and <level> represents a value from the defined levels. All level definition parameters are optional.

Level definitions will determine the amount of information collected by the corresponding Loggers.

Handler Definitions

In the system, it is possible to define an arbitrary number of Handlers. Each Handler is uniquely identified by its own name. Handlers are characterized by a set of parameters. By default, Handlers manage all the output provided by Loggers, but the output can be filtered by setting the level per Handler.

For instance, one might want to create a distinct file for logging errors exclusively and yet another file for capturing all the output specified by the global level definition.

A section that defines a Handler with all the possible parameters has the following structure:

  • handler.<name>.type=<type>
  • handler.<name>.level=<level>

where <name> denotes the handler's name, <type> defines the type of the handler and the output format, and can be one of the defined handler types. <level> can be chosen from the defined logging levels.

In order to write the logs to a text file the property 'handler.connectlog.type' should be changed to textfile as follow. The default value is console_out. The log file can be downloaded from the connect gateway endpoint.

URL - https://<>/int/soapgateway?log=true


Batch Processor troubleshooting

Application flow that involves Batch Processor typically starts in the database and end with sending a message to an external system. An error can occur in any stage of the flow execution and may require different approach to surround the problem. Message processing can involve following steps:

  • PLSQL Access Provider creates an Application Message.
    A suitable method in PLSQL Access Provider is called from PL/SQL Business logic. A new Application Message record in state Released is then created and inserted to the FNDCN_APPLICATION_MESSAGE_TAB table. A database trigger on this table, after changing the record state to Processing, is send a JMS message. An error that occurs during this process (in PLSQL AP or trigger) will cause the entire transaction initiated by the business logic to be rollbacked and no JMS be sent.
  • In house built message queueing framework is storing JMS messages in database table BATCH_PROC_QUEUE_TAB.
  • Runtime Exception that occurs during message processing by the Bach Processor's Message Driven Bean will cause the entire transaction to be rollbacked and the JMS message in the application is marked for redelivery. If the processing will continue failing after a number of attempts, the JMS message will be suspended in the JMS queue.
  • An error that occurs during the message processing by the Batch Processor code in the connect container will cause the Application Message to be set to state Failed with proper error message saved on the message.

Monitoring JMS Message in the Database

JMS Message created in the database side relevant to an application message can be monitor using Solution Manager page Batch Processor Queue.

Details of a JMS message can be also seen.