Solace and Axway Part 5 | Streams v2 Tech Preview

Axway Streams
Axway Streams

In my first three posts about Axway and Solace, I showed you how Axway could enhance messages to integrate with Solace via their JMS and REST Clients. In my last post, I showed how we could take that foundation and utilize the Axway Integration Builder iPaaS to use prebuilt connectors to enhance a third-party SaaS application by enabling real-time monitoring of their APIs to generate Events that could be integrated with Solace. But yet one use case remains untouched. What about your internal and ground-based APIs?

In the fifth entry to my blog series, I explore how to augment your existing API infrastructure with an event-driven layer using Axway Streams v2 (BETA) to connect to the Solace Event Broker.

Axway Streams: Overview

In this post, we will create a topic in Streams that takes a standard request/response API and turns it into a streaming API. After that, we will subscribe to that topic using a Webhook that will POST the deltas in the API data to the Solace Event Broker via the REST Client.

Note: This post is using Axway Streams v2, which is in BETA status and only available today to early adopters. Some of the functionality you see will be enhanced and some may be subject to change before the GA.

Prerequisites

This post operates under the assumption you already know how to work with the Solace and the Axway API Gateway (APIGW), and to start, set the Solace REST Client up to listen to a topic of your choice (e.g., test/streams) and pull up the APIGW policy we built in the second blog post to connect to the Solace REST Client.

Looking for a refresher? For detailed instructions on how to set up the steps not covered in this post, check out my previous blogs below:

Setting Up Streams

Axway’s Streams v1 is available today as a SaaS service offering. The new Stream v2 will be available in other formats, including delivery as containers for on-prem deployment. For my testing, I ran the solution in a series of containers using docker-compose. Given the BETA status, I choose not to document the specifics of the initial product configuration as this may be subject to change before the GA release.

Once Streams is running, it is time to configure it.

  • Start by using the Streams Management REST API to monitor a request/response API and transform it into a streaming API. This API stream will be referenced as a Topic with an HTTP Poller monitoring for changes and Publishing them. It will also allow for Subscriptions via Webhook.
    • topicName: Your choice, this is an alias.
    • url: This will be the endpoint you wish to monitor and publish changes about.
    • pollingPeriod: Frequency to check for and publish updates.
    • payloadType: I used “snapshot” for my testing.
    • allowedSubscriptionModes: This is described more in the documentation, but a patch Sub is going to publish only the delta, not the full text when changes occur.

  • Once you have created your Topic to monitor the URL, it is time to Subscribe using the Webhook Subscribers API. This will allow you to select a Topic and POST the changes to a specified endpoint when they occur.
    • subscriptionMode: In the above setup we limited the mode to patch, but we could have allowed for the full snapshot to be returned as a choice. While we could leave this as default, we set it explicitly here.
    • webhookURL: This is the URL you will be Publishing the events via a Webhook. Solace requires HTTP Basic credentials to be passed for integration with their REST Client. Support for this is planned to be included in the Streams v2 GA release. For now, we will send the Events to our API Gateway to add authentication information and broker the integration between Streams and Solace.

It’s that simple! At this point you are monitoring an API endpoint at a specified poll rate, converting it from a request/response to a real-time streaming API. Changes are then Published via Webhook the endpoint we Subscribed.

Configure the API Gateway

The configuration here will be very similar to that of my second blog post in this series. I made two changes to my API Gateway policy to broker this integration.

  • I added an HTTP Header filter to enhance the message with the HTTP Basic auth needed to connect to the Solace Event Broker REST Client. I could have stored the credentials securely and added them in the Connect to URL filter, but I did it this way as a temporary solution pending the enhanced functionality in the Streams v2 GA to keep the rest of the policy unchanged.
  • With the Streams connection, we would not be getting our Topic from the message. As we demonstrated the dynamic topic mapping in the previous blog post, for simplicity sake I added a static topic to my Connect to URL filter as shown, and removed the JSON Path filter we used to collect the Topic previously.

At this point, the Axway Streams solution can POST messages to the API Gateway when changes occur with the monitored service. The API Gateway then enhances the message with credentials and relays the message to Solace.

It is worth noting here that while all we are doing is using the APIGW for basic auth integration, the possibilities extend beyond this basic use case. We could, for example, redact or remove certain fields before Publishing the data to Solace or run ICAP scans for PII or other sensitive information. In this, the API Gateway can enhance and secure the Stream before it is Published in Solace for general consumption.

Check your Solace Console

As part of the prerequisites, you should have subscribed to the topic of choice in the Solace console. Navigate to the “Try It” tab and check the responses. You should see the integration working, with Streams publishing the deltas in the API being monitored every three seconds.

… and just like that we have taken a standard request/response API and transformed it into a Streaming API that anyone can Subscribe to within the Solace Event Broker.

Conclusion

Be in on-prem APIs, third-party cloud app APIs, or even just general messages, Axway can help with all your hybrid integration needs. This extends beyond APIs as well, for example, to legacy SOAP/XML messages. Any data, any format, any message, anywhere, Axway can help.

Thanks for joining us on this journey as we have explored integrating Axway API Management, Integration Builder iPaaS, and Axway Streams with the Solace Event Broker. Hopefully, you have seen how Axway can help you to evolve your current enterprise architecture to take advantage of Event-Driven architectures and powerful tools like the Solace PubSub+ Event Broker.

This is just the tip of the iceberg, a brief exploration of minimal viable solutions for integration. Interested in diving deeper? Reach out to Axway or Solace to hear about success stories where we are working together and find out how we can work #BetterTogether to help you realize your digital evolution goals! Read more: Download this white paper to learn more about Streams.

Register for our Solace/Axway Webinar: Let’s talk about Event-Driven Innovation:

 

Previous articleAxway AMPLIFY™ Central Order Signing
Next articleGA Release of Titanium SDK 9.0.2
Daniel Wille is an Axway AMPLIFY Platform architect focused on helping our clients accelerate their digital transformation journey. Daniel is a long time member of the Solution Architecture team and brings a unique perspective having implemented solutions from every major product line and several minor ones as well, and having managed the Axway US Federal technical team for nearly half a decade, with a focus on enterprise security, governance, and observability on large and complex “can’t fail” mission-critical systems. He is passionate about extending customer relationships beyond the current project with a longer term goal of becoming a trusted adviser, and exploring continued efforts to bring greater value to businesses and agencies via digital disruption.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.