We have deployed the App Connect 12.0.5.0 HTTP application on a Linux server. It has a message flow which starts with a http input node and ends with a http reply node, along with some other nodes for business functions. In the last few days, 1 transaction has failed due to a timeout on the channel. It took exactly 1 minute for the client application to post a request at 07:59:35 and the ace application to receive it at 08:00:35. As per the audit logs of ace service the transaction has been started to process at 08:00:35 not at 07:59:35. Since we are using node wise http listener , we have only the time which the ace application started the processing of the request, not the time of the request which was landed on the server.

 Kindly assist us in determining the landing time of an HTTP request that was received at the ACE HTTP application using a broker-wide HTTP listener.

@Anoop C Pillai,
According to your issue, sending the request at 07:59:35 and the flow starts processing at 08:00:35, doesn't mean that the issue from ACE service itself, maybe there is an issue in the clients application side, firewalls or from networking configurations.

We have deployed the App Connect 12.0.5.0 HTTP application on a Linux server. It has a message flow which starts with a http input node and ends with a http reply node, along with some other nodes for business functions. In the last few days, 1 transaction has failed due to a timeout on the channel. It took exactly 1 minute for the client application to post a request at 07:59:35 and the ace application to receive it at 08:00:35. As per the audit logs of ace service the transaction has been started to process at 08:00:35 not at 07:59:35. Since we are using node wise http listener , we have only the time which the ace application started the processing of the request, not the time of the request which was landed on the server.

 Kindly assist us in determining the landing time of an HTTP request that was received at the ACE HTTP application using a broker-wide HTTP listener.

Dear Ahmad Taha,

Whether there is a way to determine when the request arrived at the ACE server the time , considering that the HTTP listener uses system queues and the request initially reaches here. This is to determine whether there has been any network issue.

Regards,

Anoop

@Anoop C Pillai,
According to your issue, sending the request at 07:59:35 and the flow starts processing at 08:00:35, doesn't mean that the issue from ACE service itself, maybe there is an issue in the clients application side, firewalls or from networking configurations.

We have deployed the App Connect 12.0.5.0 HTTP application on a Linux server. It has a message flow which starts with a http input node and ends with a http reply node, along with some other nodes for business functions. In the last few days, 1 transaction has failed due to a timeout on the channel. It took exactly 1 minute for the client application to post a request at 07:59:35 and the ace application to receive it at 08:00:35. As per the audit logs of ace service the transaction has been started to process at 08:00:35 not at 07:59:35. Since we are using node wise http listener , we have only the time which the ace application started the processing of the request, not the time of the request which was landed on the server.

 Kindly assist us in determining the landing time of an HTTP request that was received at the ACE HTTP application using a broker-wide HTTP listener.

Dear Anoop,

To troubleshoot performance issues within your integration flows, I recommend the following approach:

1. Utilize Trace Node: Insert a Trace node after each node within your Message flow. Configure the Trace node to log messages to a file, including the following information: 
    * ${CURRENT_TIMESTAMP} 
    * ${Root} 
    * ${Environment}
    * ${ExceptionList}

2. Enable Tracing:  Deploy your application and enable tracing for the specific nodes using the command: 
   `mqsichangetrace <NODE> -e <IE> -n on`

3. Generate Log Data:  Run a few test transactions to generate log entries.

4. Disable Tracing: Disable tracing using the command: 
   `mqsichangetrace <NODE> -e <IE> -n off`

5. Analyze Logs: Review the generated log files to identify potential bottlenecks within the flow.

for Further Information: Trace node - IBM Documentation

Long-term Logging Solution:

For robust and comprehensive logging, I recommend implementing a dedicated logging solution. This could involve utilizing technologies such as databases (e.g., Oracle, SQL Server, or a NoSQL database like MongoDB), Log4j, or the Elastic Stack (ELK). These solutions can effectively capture detailed request/response logs, error messages, and timestamps (in milliseconds) for each flow.

Furthermore, to improve system observability and troubleshooting, I recommend adopting a microservices architecture. By breaking down the integration flow into smaller, independent services, each with well-defined responsibilities, you can:

• Improve Fault Isolation: Isolate issues to specific services, making troubleshooting and debugging more efficient.
• Enhance Scalability: Scale individual services independently based on their specific needs.
• Improve Maintainability: Simplify development, testing, and deployment by breaking down complex flows into smaller, more manageable units.

By implementing these recommendations, you can significantly enhance the observability, maintainability, and overall performance of your integration solution.

Best regards

Dear Ahmad Taha,

Whether there is a way to determine when the request arrived at the ACE server the time , considering that the HTTP listener uses system queues and the request initially reaches here. This is to determine whether there has been any network issue.

Regards,

Anoop

@Anoop C Pillai,
According to your issue, sending the request at 07:59:35 and the flow starts processing at 08:00:35, doesn't mean that the issue from ACE service itself, maybe there is an issue in the clients application side, firewalls or from networking configurations.

We have deployed the App Connect 12.0.5.0 HTTP application on a Linux server. It has a message flow which starts with a http input node and ends with a http reply node, along with some other nodes for business functions. In the last few days, 1 transaction has failed due to a timeout on the channel. It took exactly 1 minute for the client application to post a request at 07:59:35 and the ace application to receive it at 08:00:35. As per the audit logs of ace service the transaction has been started to process at 08:00:35 not at 07:59:35. Since we are using node wise http listener , we have only the time which the ace application started the processing of the request, not the time of the request which was landed on the server.

 Kindly assist us in determining the landing time of an HTTP request that was received at the ACE HTTP application using a broker-wide HTTP listener.

Dear Ahmad Taha,

Yes, I have a well-defined logging solution that logs the data into the database and trace files.  However, I need the time when the request landed in the ACE broker, not the time when the message flow started processing. 

Regards,

Anoop

Dear Anoop,

To troubleshoot performance issues within your integration flows, I recommend the following approach:

1. Utilize Trace Node: Insert a Trace node after each node within your Message flow. Configure the Trace node to log messages to a file, including the following information: 
    * ${CURRENT_TIMESTAMP} 
    * ${Root} 
    * ${Environment}
    * ${ExceptionList}

2. Enable Tracing:  Deploy your application and enable tracing for the specific nodes using the command: 
   `mqsichangetrace <NODE> -e <IE> -n on`

3. Generate Log Data:  Run a few test transactions to generate log entries.

4. Disable Tracing: Disable tracing using the command: 
   `mqsichangetrace <NODE> -e <IE> -n off`

5. Analyze Logs: Review the generated log files to identify potential bottlenecks within the flow.

for Further Information: Trace node - IBM Documentation

Long-term Logging Solution:

For robust and comprehensive logging, I recommend implementing a dedicated logging solution. This could involve utilizing technologies such as databases (e.g., Oracle, SQL Server, or a NoSQL database like MongoDB), Log4j, or the Elastic Stack (ELK). These solutions can effectively capture detailed request/response logs, error messages, and timestamps (in milliseconds) for each flow.

Furthermore, to improve system observability and troubleshooting, I recommend adopting a microservices architecture. By breaking down the integration flow into smaller, independent services, each with well-defined responsibilities, you can:

• Improve Fault Isolation: Isolate issues to specific services, making troubleshooting and debugging more efficient.
• Enhance Scalability: Scale individual services independently based on their specific needs.
• Improve Maintainability: Simplify development, testing, and deployment by breaking down complex flows into smaller, more manageable units.

By implementing these recommendations, you can significantly enhance the observability, maintainability, and overall performance of your integration solution.

Best regards

Dear Ahmad Taha,

Whether there is a way to determine when the request arrived at the ACE server the time , considering that the HTTP listener uses system queues and the request initially reaches here. This is to determine whether there has been any network issue.

Regards,

Anoop

@Anoop C Pillai,
According to your issue, sending the request at 07:59:35 and the flow starts processing at 08:00:35, doesn't mean that the issue from ACE service itself, maybe there is an issue in the clients application side, firewalls or from networking configurations.

We have deployed the App Connect 12.0.5.0 HTTP application on a Linux server. It has a message flow which starts with a http input node and ends with a http reply node, along with some other nodes for business functions. In the last few days, 1 transaction has failed due to a timeout on the channel. It took exactly 1 minute for the client application to post a request at 07:59:35 and the ace application to receive it at 08:00:35. As per the audit logs of ace service the transaction has been started to process at 08:00:35 not at 07:59:35. Since we are using node wise http listener , we have only the time which the ace application started the processing of the request, not the time of the request which was landed on the server.

 Kindly assist us in determining the landing time of an HTTP request that was received at the ACE HTTP application using a broker-wide HTTP listener.