Welcome to the fourth installment of this blog post series, where I interview SAP Cloud Integration practitioners, developers, architects and enthusiasts about their favourite feature of the platform. This time around, I’m talking to vadim.klimov, who is known for his always interesting and insightful contributions to the SAP Cloud Integration community. Vadim also co-wrote the literal book on Groovy scripting in SAP Cloud Integration, so today’s topic probably won’t be a total shock to you 😄
Could you introduce yourself briefly, please?
My name is Vadim Klimov, I'm a freelance SAP integration architect based in the United Kingdom. I enjoy the spirit of the SAP Community and try to contribute to it. I'm also the co-author of an SAP PRESS book about scripting in SAP Cloud Integration.
Thank you! On to the central question of this blog post series: What’s your favourite SAP Cloud Integration feature?
Scripts - developed in Groovy or in JavaScript - that can be added to an integration flow, are definitely one of my most favourite features.
Why that particular feature?
SAP Cloud Integration provides a feature-rich palette of flow steps, but there is a wide spectrum of integration requirements that cannot be easily fulfilled using only standard steps. This is where scripts come to the rescue. Scripts make it possible to implement very sophisticated logic that is highly tailored to specific requirements using custom-developed Groovy or JavaScript script functions.
Custom scripts can efficiently use SAP and 3rd party libraries; there is no need for an integration developer to implement the entire script from scratch. Some building blocks of the developed script can rely on the functionality offered by corresponding libraries, making the script development process more rapid. It goes without saying that there are various aspects to take into account and assess when considering the usage of external libraries; licensing, the credibility of the library, maintenance and support, security and performance, and transient dependencies of the library to name a few.
Scripts can be reused across integration flows, thanks to script collections. This contributes to the reusability of developed scripts and makes it possible to develop general-purpose scripts once and apply them to many different integration flows.
How do you see this feature evolving going forward?
When the SAP Cloud Integration runtime gets upgraded and supports newer releases of, for example, Groovy, integration developers shall be able to leverage new features of the Groovy language, and new APIs of the Groovy SDK. That will provide an opportunity to create even more elegant and efficient scripts that are easier to develop and maintain.
In the longer term, I would love to see more native support offered by SAP for standalone testing of developed scripts, a convenient way for integration developers to create unit tests, execute and profile scripts under test in a local lightweight, but representative environment. There are currently ways to achieve this using some advanced techniques, but those are based on community efforts and are not a part of the SAP official tooling.
Following examples of approaches to provision runtimes for some other cloud-native technologies and to use them locally in a development environment, I lean toward the idea that containerization technologies (such as those based on Docker) can be instrumental here. Taking into consideration that SAP Integration Suite already travels the path of containerization - for example, the deployment model of the eagerly-anticipated Edge Integration Cell component is purely based on Kubernetes - it makes me believe that there is a potential for the release of a lightweight containerized runtime of SAP Cloud Integration that can be deployed and used in a local development environment for local testing purposes.
Indeed, a fully-fledged SAP Cloud Integration runtime has many dependencies on other services and capabilities, and it is hardly technically feasible and highly impractical to try to bring them all to a local environment, but even a significantly minified flavour of a worker node of SAP Cloud Integration accompanied by mocks for service dependencies, could be of immense use for integration developers.
Also, I'm very much interested to see how runtime safety for deployed and executed scripts may be improved. Scripting in SAP Cloud Integration provides a flexible and powerful way to extend integration flows, but scripts can also become a root cause of severe performance and even security issues at runtime if used prematurely and unwisely. In the most extreme cases, such scripts can become poisonous and malicious and impact the stability and operations of the entire worker node of an SAP Cloud Integration tenant and the integration flows that are deployed on it.
Configurable mechanisms that can be used to restrict classes that are accessible from within scripts (class allowlisting technique) can be one of the options that I can think of here. Dynamic programming and metaprogramming techniques that can be utilized when using Groovy, reduce the accuracy of identification of such risks purely using static code analyzers (this is not intended to suggest that static code analyzers shall not be used when developing scripts - quite the opposite, it is strongly encouraged to use them to improve script code quality). I see a need for tools that can inspect executed scripts at runtime continuously, but with low performance overhead - for example, by analyzing information offered by classloaders and some other internal mechanisms offered by the JVM - and that can be used by SAP Cloud Integration to make its runtime more secure and protected against script malfunctions.
Thanks a lot for taking the time to do this interview, Vadim!
- SAP Managed Tags:
