Skip to Content
Personal Insights

SAP CPI as a Microservice

I was working on a PoC to see if I could convert an XML document to PDF on the SAP CPI platform. Surprise it was possible. In that process, I considered if it was a microservice that I had created. In some narrow cases, it thinks it can be used as a microservice.

What is a microservice?

Wikipedia defined a microservice as

Microservices are a software development technique —a variant of the service-oriented architecture (SOA) structural style— that arranges an application as a collection of loosely coupled services.[1] In a microservices architecture, services are fine-grained and the protocols are lightweight.

There are some different examples of it and what is supposed to be doing. CPI does check such definitions in the way you can expose things.

Serverless

There is also the concept of serverless where you just call functions. In CPI you are limited to the resources assigned to your instance you cannot scale above that. But for low used functions, it may make sense to run in in CPI.

SAP CPI Microservices

You can create independent Iflows that you can then build up to larger applications that control your business. It can use the ProcessDirect adapter to communicate fast within the application.

The CPI will ensure you scale the application, to the limits of what you can perform in the node.

There are people that have to build some cool consumer-facing applications to manage and monitor SAP CPI like Raffael Herrmann Realcore Dashboard or Ariel Bravo Ayala  CPI Scheduler Monitor. Here the user can see a simple webpage and then call some rest services from the backend.

A lot of Microservice example is about fetching some data via an API and perform some action on the data and return it to the caller. This is what SAP CPI is doing for a living, so here it makes a lot of sense. So in some PoC it may make sense to create the services here.

Limitations

CPI is not built as a microservice framework. I guess one of the big elements that it does not contain is the ability to database access. You can access databases via the CPI adapters or using the CPI datastore directly from your Groovy script. It may take a long time to develop applications this way.

And another big challenge is that you can not add other frameworks like Spring(i assume). So it needs to be services that only account for something that can be handled in a Groovy script with some archives.

I think the big thing is that you can assign specific memory to each application so it can run much larger. I think CPI is limited to 2 or 4 GB memory per node, and all iflows is deployed on each node. The PDF example is about 14 MB libraries, and I would assume this is increased once deployed to memory, plus each running instance will consume some resources.

Cloud Foundry

Sure the answer to Microservices is using Cloud Foundry for such processes where you want to access and orchestrate data. CF has access to databases, frameworks, APIs, scalability, and security. It is obvious something the best solution to build a real application in that way. If you want to learn more check out some of the Open.SAP.com courses.

It does require you have it as a strategy, which I would assume everybody needs to in the near future. Or run it in a similar solution at the cloud scalers or on their own Kubernetes environment.

Conclusion

I think CPI microservices does make sense in a small way. There are some services that can be created if you just want a small Java service to help with conversion between format. Like XML to PDF but also XML to Word etc. It does also have the ability to call APIs and translate external data into readable information.

I will never recommend building a full scope application/landscape with microservices deployed in the SAP CPI. I do think it makes some sense if you want to experiment and figure out which services you need.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.