ArganoMS3 | Cloud Integration Solutions

In this video blog, ArganoMS3’s Director of Technology, Joe Rice, discusses how Kong Konnect enables instant access to purpose-built multi-cloud connectivity across APIs and microservices. Learn more at https://konghq.com/kong-konnect

Watch by clicking below:

Instant Multi-Cloud API and Microservice Connectivity

Financial institutions have spent millions of dollars and many years cycling through different API governance and integration ecosystems using traditional rest-centric API gateways, complex service mesh technology or even homegrown approaches that eventually are too difficult to manage or maintain. 

But with the advent of the Cloud, containers can provide a lightweight and flexible way to add value (not latency) and scale without adding single points of failure. The traditional monolithic, shared gateways that I’ve seen don’t do that. They’re not container- and cloud-ready. They’re not lightweight and easy to distribute. 

I’ve seen implementations of Apigee, Mulesoft, API Connect, cloud native gateways and even appliance-based solutions that at the end of the day are monolithic and essentially monotone. They do one thing well, such as a REST API, but lack the flexibility that’s needed for the modern enterprise. They are complex and heavyweight, albeit feature-rich. While they do deliver the base routing, bridging transformation and connectivity, they have limits in formats and impose lock-in via a high-friction, vendor-specific process.

But the Kong service connectivity platform, via the connect ecosystem, is different. It allows you to outsource the management of the control plane, hosting it in data centers while still being able to locally control policy enforcement and data, whether it be an Amazon, Google, Azure or in your local data centers.

Being able to deliver vital observability, zero-trust security, pluggable extensibility with well-organized ways to find and reuse APIs, and a catalog along with industry standard controls and guardrails to authenticate, authorize, identify and only allow legitimate access to trusted resources. 

So what else can it do? It’s not a one-trick pony. It cannot just do REST but gRPC, GraphQL and events. It can run anywhere – standalone Kubernetes or the cloud. 

It’s full-lifecycle with DevOps automation, and it’s container-optimized with the observability and flexibility needed via either distributed service mesh or lightweight gateways. 

With the latest release, it’s even satisfying the need for multi-geography support (US, UK, Germany, Japan and Australia) to provide and comply with data sovereignty and local regulations. 

And it’s available either as a free open source solution through Kong Konnect Free, Kong Konnect Plus (a pay-as-you-go approach), or Kong Konnect Enterprise to deliver enterprise-grade security, scalability, observability and more.

But is it easy to set up? Watch this video where I walk you through what I was able to do in a very brief period of time by just signing up for Konnect. They’ll set up a Kong Konnect environment for you, which is basically the control plane of the Kong Gateway ecosystem.

There’s no faster or easier way to set up robust, cloud native, container-ready Zero-trust security that’s format- and protocol-agnostic. Check it out today.

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

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

About

Solutions

Partners

Popular Links

COPYRIGHT © 2022 ⬤ ArganoMS³ MOUNTAIN STATE SOFTWARE SOLUTIONS