Posts

Showing posts with the label ESB

WSO2 ESB - How to track messages between mediation flows

Image
WSO2 ESB Services / APIs for Enterprise level applications, usually consume services deployed in other WSO2 products like DSS, BRS etc., or use services deployed in some legacy or third party application (can call, backend services) in order to complete the service request.

This means you have multiple endpoints configured and used, across different sequences encomposing the service.

Keeping track of these internal message flows between various services is important to debug service flows. This is more important and complex when debugging services which involves service timeouts and client or backend service errors.

Thankfully, as per the WS-Addressing specification, each message is assigned a unique message identifier or Message ID.
Synapse Engine takes care of the same and every Message is assigned an unique message ID.

Its available as MessageID and its a Synapse context message property that can be retrieved using the get-property() function in the Property mediator.

<property …

WSO2 ESB - Disable Endpoint Suspension

Endpoints An endpoint in simple terms is a URL (destination) that can be used by any WSO2 service which needs to send a message to that particular destination / API. 
The endpoints can be configured for both external services and also internal, peer services running inside the same ESB instance or the host system. 
One of the important configurations that is often overlooked are the endpoints error handling.  As any network oriented application, messages can get lost due to various tcp errors, connection timeouts, etc., Therefore for a successful and controlled behavior, endpoint error handling is very important. 
The default behavior of endpoints in WSO2 is, if messages in those endpoint are failed, the endpoint will be marked as "suspended" and thereby causing failure of the subsequent messages. 
This is more important if multiple internal services are consumed as part of an exposed Proxy service or API. To handle the different errors and timeouts from the internal servic…

WSO2 - Registry setup

Image
All WSO2 products are shipped with a built-in registry, supported by the H2 Database packaged with the product. Though its sufficient for many applications, its not recommended for Enterprise integration applications and Production environments.

In our case the ESB registry is mounted with WSO2 Governance Registry (GREG). The below steps can be used to change the ATOM based registry mount (default) with JDBC based mount.

The following example was implemented on the systems which had deployed resources and services, servicing other applications.

GREG 1. In GREG, replace WSO2_CARBON_DB in master-datasources.xml with JDBC details.

<datasource>
   <name>WSO2_CARBON_DB</name>
   <description>The datasource used for registry and user manager</description>
   <jndiConfig>
        <name>jdbc/WSO2CarbonDB</name>
   </jndiConfig>
   <definition type="RDBMS">
       <configuration>
           <url>jdbc:oracle:thin:@172.17.…