ArganoMS3 | Cloud Integration Solutions

  • About
    • Why Us
    • Leadership
    • Our Core Values
    • Clients
    • ArganoMS3 PHILIPPINES
  • Services & Expertise
    • API & INTEGRATION
      • Tavros
      • KONG API
      • MuleSoft
      • APIGEE
      • REDHAT FUSE / CAMEL
    • STRATEGY & OPTIMIZATION
      • DEVOPS
      • 24x7x365 Ops Support
    • CLOUD SERVICES
      • AMAZON AWS
      • SALESFORCE
    • ARTIFICIAL INTELLIGENCE
      • RPA
      • BIG DATA
      • IoT
  • Partners
    • MuleSoft
    • AWS
    • UiPath
    • Kong
    • Apigee
    • Red Hat
  • Resources
    • ArganoMS3 Is Talkin’ Nerdy
    • Case Study
    • MUnit Whitepaper
    • MuleSoft Runtime Whitepaper
    • API-Led Architecture Whitepaper
  • Careers
  • Blog
    • Archive
  • Contact

Creating an HTTP Outbound Logger
Using Mule’s Server Notifications

Marcos Villalba

INITIAL REQUIREMENTS

The task at hand required us to create some kind of listener/interceptor to be triggered whenever we were about to hit a http outbound component. This logger was supposed to write down URL and payload of the http outbound call we were about to do.

Other requirements were to be reusable, easy to add to any project, and have the ability to connect/disconnect via config files. All of this combined would make for quite a useful tool for testing and troubleshooting.

FIRST APPROACH

We started with an out of the box interceptor – this approach is quite useful for attaching behavior to Mule components. All official docs here.

Simply adding interceptor components in our flow, and referring them to a java class, implementing EnvelopeInterceptor or AbstractEnvelopeInterceptor Interfaces, flow will be intercepted.

<flow name=”interceptorFlow”>
    <http:listener config-ref=”HTTP_Listener_Configuration” path=”/input” doc:name=”HTTP”/>
    <set-payload value=”#[‘sample payload’]” doc:name=”Set Payload”/>
    <custom-interceptor class=”com.ms3.logging.interceptor.LoggingInterceptor” />
    <http:request config-ref=”HTTP_Request_Configuration” path=”destination_path” method=”GET” doc:name=”HTTP”/>
</flow>

With an implementation class:

public class LoggingInterceptor extends AbstractEnvelopeInterceptor implements Interceptor{
    @Override
    public MuleEvent process(MuleEvent event){
        //flow intercepted!

        //lets do something here!
        return event;
    }
}

At this point, we are free to recover the message context, flow variables, payload, etc and process them how we see fit.  However, this approach was not successful in providing us the needed URL and payload content.

Now we ask, why was this approach unsuccessful? Well, our objective was to intercept the flow, and access http outbound transport parameters (host,port,path etc). These variables belong to the http component and not to the flow or message, so an alternative approach was needed.

In conclusion.. we need to go deeper and listen to the http component directly!

we-need-to-go-deeper

MULE SERVER NOTIFICATIONS

Mule provides an internal notification mechanism that you can use to access changes that occur on the Mule Server, such as a flow component being added, a Mule Model being initialized, or Mule being started. You can set up your agents or flow components to react to these notifications.

Message notifications that are fired by the code provide a snapshot of all information sent in and out of the Mule Server, and are fired whenever a message is received or sent. All official docs here.

In other words, our developer friends from MuleSoft fire thousands of notifications when different events happen deep inside the code. We can catch these notifications and use it in our favor and get some insight to what is happening within our applications.

THE ArganoMS3 IMPLEMENTATION

In our particular case, we want to listen/catch a notification that is being fired by the http component (DefaultHttpRequester) just before the actual network call. At this particular moment, We will ask the component “hey, what is the URL,port,path.. you are about to hit?” It will provide us with the necessary information that we can then record. So lets get to work and show you how it is done.

All of these notifications fired by the code are disabled by default because of if left on there would be significant performance impact, So we need to enable them and then inject a java class that will be used to handle the notifications. Here is the mule configuration elements to enable events and the receiving class.

<spring:beans>
    <spring:bean name=”messageProcessorListener” class=”com.ms3.httpListener.HttpNotificationListener”/>
</spring:beans>

<notifications>
    <notification-listener ref=”messageProcessorListener” />
</notifications>

Our class HttpNotificationListener will be listening for notifications that will be firing from within the core Mule code, but… which notifications will we get? There will be hundreds fired per second, so we need a way of selecting which ones are the ones that we are looking for and filter all the rest of the noise out of the class.

For this, we need to select which interface our class will be implementing. Mulesoft gives the developers a list of all the possible NotificationListener interfaces, each one of them will be triggered under a particular situation/change/scenario. Here’s a complete list.

Some dev notes here:

  • We selected MessageProcessorNotificationListener, triggered whenever a message processor was invoked. Since this is quite generic, we narrow it by listening to DefaultHttpRequester processor.
  • All classes implementing NotificationListener must implement method onNotification().
  • The input parameter of this method will depend on the NotificationListener used.
  • Once the method is triggered, we can access all the parameters of the current message processor. In our case, the desired DefaultHttpRequester.
public class HttpNotificationListener implements MessageProcessorNotificationListener<MessageProcessorNotification> {

    @Override

    public void onNotification(MessageProcessorNotification notification) {

        MessageProcessor messageProcessor = notification.getProcessor();

        if(messageProcessor instanceof DefaultHttpRequester)

        {

        DefaultHttpRequester httpRequester = ((DefaultHttpRequester) messageProcessor);

        String msgId = notification.getSource().getMessage().getMessageRootId();

        String outbound_URL =              httpRequester.getHost()+”_”+

        httpRequester.getPort()+”_”+

        httpRequester.getPath()+”_”+

        httpRequester.getMethod();

        //log all this info somewhere!

        }

    }

}

CONCLUSION

Mule Server notifications are an extremely flexible, powerful Mule capability. Since there is not much documentation out there,  you will need to dive into Mule´s source code to see what notification is being fired in the part of the code you are interested in interacting with.

Dont be shy!
Contact ArganoMS3 today to see how we can help you with your Mulesoft project contact@ms3-inc.com

 

LINKS

Filed Under: Integration, Mulesoft Tagged With: Anypoint, Debug, HTTP, HTTPS, Interceptor, MS3, Mulesoft, Outbound HTTP, Testing

FUTURE PROOF SOFTWARE SOLUTIONS
ArganoMS³ enables organizations to meet today’s software, integration, cloud, and data-related challenges with confidence and ease.

About

  • Why Us
  • Leadership
  • Team
  • Clients
  • We're hiring

Solutions

  • API & Integration
  • Strategy and Optimization
  • Cloud Services
  • Artificial Intelligence

Partners

  • Apigee
  • AWS
  • Kong
  • MuleSoft
  • Red Hat
  • Salesforce
  • UiPath

Popular Links

  • Contact Us
  • Blog
  • White Papers
  • Case Study
COPYRIGHT © 2022 ⬤ ArganoMS³ MOUNTAIN STATE SOFTWARE SOLUTIONS

Copyright © 2023 · MS3 Mountain State Software Solutions · Log in