2013/10/01
1 Oct, 2013

WSO2 Enterprise Service Bus Balance SugarCRM Proxy Service

  • Antonio Musarra
  • IT Senior Consultant - WSO2

I received several inputs to explore the topic and Proxy Service then so be it. The case study (then very close to the real) that I’m going to offer you, will always treat the theme of the Proxy Service (on WSO2 Enterprise Service Bus ) towards services SOAP exposed by SugarCRM, but introduces the mechanisms of processing of the message a little more complex.

1. Presentation of the case study

Within our hypothetical company all systems communicate with each other through an Enterprise Service Bus (ESB), which in our case is implemented using the WSO2 ESB solution. Systems “register” communicate by means of ESB through appropriate interfaces / connectors and always ESB regulates the flow of messages. Figure 1 shows the pattern of integration of business systems on ESB.

Access to the data of CRM (implemented by SugarCRM solution) must be made ​​by means of a Proxy Service exposed on ESB, adjusted on the basis of the network on which the request and as a final requirement, balanced on several instances of the backend services exposed by the CRM. In summary, the Proxy Service to configure ESB must do the following:

  1. Trace the IP of who is requesting access to the service;
  2. Filter access to backend services to allow access only to trusted networks:
  • 10.1.1.0/28 (internal network department Sales)
  • 10.1.2.0/28 (internal network Marketing Department)
  • 10.1.3.0/28 (internal network Customer Support department)
  • 196.168.1.0/255 (partner network)
  • Managing the refusal of access to the service through a fault message;
  • Balance the access request to the service on the nodes that are part of the system of CRM:
    • CRMNODE0 (crm-node0-shiruslabs.dontesta.it)
    • CRMNODE1 (crm-node1-shiruslabs.dontesta.it)
    • CRMNODE2 (crm-node2-shiruslabs.dontesta.it)

    The flowchart of Figure 2 summarizes the flow previously proposed. The filtering operation on the IP source of the request message is performed based on a regular expression , built in such a way that only the networks mentioned above successfully pass the filter. The regular expression is as follows:

    • (10\.1\.1\.(1[0-4]|[1-9]))|(10\.1\.2\.(1[0-4]|[1-9]))|(10\.1\.3\.(1[0-4]|[1-9]))|(192\.168\.1\.(25[0-4]|2[0-4][0-9]|1[0-9]{2}|0[1-9][0-9]|00[1-9]))

    The diagram of Figure 3 shows the flow of a request for access to the service of CRM by a generic application. The Proxy Service exposed by the ESB is configured on the HTTP / S. For this particular case (see Figure 3), the request was made ​​(by the component LBE) to the node service CRMNODE2 which is part of the entire CRM system.

    2. Overview of Messaging architecture

    Before continuing with the configuration of the Proxy Service we make a brief review on the architecture of messaging and the elements that make up the architecture, elements that we will use to configure the Proxy Service. WSO2 ESB is a comprehensive platform and enterprise-level project built on the Apache Synapse , this project uses the Apache Axis2 engine for the Web Services . In Figure 4 is shown the high level architecture of Apache Synapse (the base of WSO2 ESB) while Figure 5 shows the more specific architecture of WSO2 ESB from the perspective of the messages.

    The diagram in Figure 5 shows how a request is propagated to the endpoint via the ESB. All the basic elements shown in Figure 4 can be managed and monitored through the management console ESB.

    The architecture of WSO2 has several components but we see briefly describe the basic ones that then will use in the realization of the Proxy Service, remembering that the latter is a component of the platform and described in the previous article WSO2 ESB SugarCRM Proxy Service .

    The transport is able to receive and send messages on a multitude of protocols, both of the level of transport of both application level (such as for example: JMS, MSMQ, TCP, HL7, etc …).

    An endpoint defines an external destination (such as a web service) for a message. An endpoint can be specified as an address endpoint, WSDL endpoint, load balancing endpoint and more. An endpoint is defined independently from the transport, and this allows to use the same endpoint with multiple transports.

    The mediators are of individual processing units that perform a specific function, such as sending messages, filtering, etc … WSO2 ESB includes a very large library of mediators that provides functionality for the implementation of the most common pattern of integration ( EIP). You can also write a mediators easily customized to your needs by using various technologies like Java, scripting languages ​​and Spring.

    The sequences are the configuration component for the mediator. The Sequences allow you to organize mediator to implement pipes and filtering models. A mediation sequence, commonly called “sequences”, is a list of mediator that are executed in order. When a message is delivered to a sequences, the sequences sends the message through all its mediator (see Figure 6).

    3. Inside the Proxy Service

    The role of ESB would be to “mediate” the incoming messages to the Proxy Service before being forwarded to the actual service on the CRM system. Ultimately the operations of the mediation shall be conducted within a mediation sequence, where each mediator will do its part, in particular:

    1. Mediator Property: it has no direct impact on the message, but rather on the message context flowing through Synapse and each property has set a scope. You can retrieve the properties set on a message and retrieve them later through the function synapse: get-property (scope, prop-name),extension of XPath. In our specific case, this mediator is used to set the client-add that will contain the source IP address of the incoming request;
    2. Log Mediator: used for logging. The information that we’re going to write to the log file are the address and the hostname of the request received;
    3. Filter Mediator: Executes the filtering using XPath with the possibility of using regular expressions. In our specific case, the filter passes the messages to the next mediator (ie closer to the final destination) if the source IP address of the message matches the regular expressionshown above, if not control passes to a mediation sequence that will send an error message (fault message) to the client. This kind of reminds of a mediator if-else control structure;
    4. Send Mediator: is used to send messages to Synapse to one or more endpoints. This type ofmediator is makes sure that it is possible the correlation between the messages sent and received.The endpoint to which the message is sent is a load-balanced-endpoint.

    In Figure 7 is shown the diagram of the mediation sequence specific to our Proxy Service, while in Figure 8 the cross-section of the load-balanced-endpoint consists of three endpoints for the respective nodes of the instances of SugarCRM.

    The load balanced endpoint distributes incoming messages between a group of endpoints by evaluating the load balancing policy. At present only the policy of Round Robin is supported by this component.

    In Figure 7 is shown a Fault Message Out, this will be returned to the client to indicate the “no access” to the service. The message will be returned to the client as a SOAP fault and responsible for building the fault message is the mediation sequence defined on ESB with the name of SugarCRMProxyLBAccessForbidden (see XML configuration to Listing 1).

    Listing 1. Configuring the Mediation Sequence SugarCRMProxyFilteredByNetLB.

    After seeing what are the essential elements of our Proxy Service does not just have to see the full XML configuration.

    Listing 2. Complete configuration of the Proxy Service SugarCRMProxyFilteredByNetLB.

    4. Testing the Proxy Service

    Using the management console, you can conduct tests on the Proxy Service you just configured.Tests that may be performed to verify proper configuration of the service are:

    1. Access to the service by a network allowed and verifying the proper operation of the service;
    2. Access to the service by a network prohibited and verification of error handling via SOAP Fault;
    3. Verification of access to the service even in case of failure of one of the nodes of the CRM system.

    We assume the first case and pass the verification of what should happen in the two remaining cases. In the second case, the client should receive a SOAP Fault and the log (via the Log Mediator)be referred to the Access Denied error to the service (see Listing 3 and Listing 4). The logs show that access to the service was properly denied because the request originates from the IP 192.168.43.226 which is not allowed between the networks, then discarded from the Filter Mediator.

    Listing 3. Entry of log files in the event of denied access to the service

    Listato 4. SOAP Fault message in the event of denied access to the service

    Turning to the third case from the list of tests, we assume that the node CRMNODE2 is offline for maintenance, in these conditions, the service should continue to respond while the ESB will mark the endpoint in a state of suspension for a specific period of time (a parameter can be configured).Listing 5 shows the entry to the log file showing the failure condition to be raised by the load balancer endpoints.

    [2013-09-05 15:57:01,329]  WARN - SourceHandler Connection time out after request is read: http-incoming-10
    [2013-09-05 15:57:16,711]  WARN - ConnectCallback Connection refused or failed for : crm-node2-shiruslabs.dontesta.it/172.16.3.100:8888
    [2013-09-05 15:57:16,716]  WARN - FaultHandler ERROR_CODE : 101503
    [2013-09-05 15:57:16,717]  WARN - FaultHandler ERROR_MESSAGE : Error connecting to the back end
    [2013-09-05 15:57:16,717]  WARN - FaultHandler ERROR_DETAIL : Error connecting to the back end
    [2013-09-05 15:57:16,717]  WARN - FaultHandler ERROR_EXCEPTION : null
    [2013-09-05 15:57:16,718]  WARN - FaultHandler FaultHandler : Endpoint [CRMNODE2]
    [2013-09-05 15:57:16,718]  WARN - EndpointContext Endpoint : CRMNODE2 will be marked SUSPENDED as it failed
    [2013-09-05 15:57:16,719]  WARN - EndpointContext Suspending endpoint : CRMNODE2 - current suspend duration is : 30000ms - Next retry after : Thu Sep 05 15:57:46 CEST 2013
    [2013-09-05 15:57:16,719]  WARN - SALoadbalanceEndpoint Endpoint [endpoint_b80e9c3ba240e757e32e2a0f6e8987ecce03191bd8a1f51d] Detect a Failure in a child endpoint : Endpoint [CRMNODE2]
    

    Listing 5. Error condition on a node of the load balancer endpoints.

    5. Resources

    To deepen the understanding on the subject you point out a series of public resources available on the website of WSO2:

    6. Conclusions

    Adding some extra complexity than if presented with the previous article WSO2 ESB Proxy Service SugarCRM , nothing has changed, no code, only configuration. Setting up a new service or edit an existing one, is a bit like doing a puzzle, I would say a tie. From the composition of the individual building blocks (such as mediator, endpoint, etc ...) with little effort you can get a product that meets its requirements, not bad. The standard platform WSO2 provides about forty mediator for many different uses and if not available one face to our case and if possible write it.

    Related Articles

    Source: https://www.dontesta.it/blog/en/blog-2/crm/wso2-esb-balance-sugarcrm-proxy-service/

     

    About Author

    • Antonio Musarra
    • IT Senior Consultant
    • Key-Biz S.r.l.