Technical Articles
Why not use JavaScript instead of Groovy script in SAP CPI
Lately I’ve been following several threads about SAP Cloud Platform Integration (CPI). The information I have gained from following these threads has helped me to improve my skills when working on SAP projects, and it has helped me develop solutions that I have regularly been able to use. I believe that this exchange of information is what makes this SAP community a valuable repository of knowledge and useful solutions to be shared among its members.
However, I have noticed very few posts that discuss JavaScript. In the 2021 Stack Overflow Developer Survey, JavaScript was found to be the most commonly used programming language, with nearly 65% of respondents using JavaScript, compared to around 35% of respondents using Java. Unsurprisingly, the number of articles and questions about JavaScript, and the number of code examples using JavaScript, is almost double those referring to Java. Perhaps one explanation for the considerable difference in the number of users of JavaScript and Java is the large number of frameworks released in recent years such as: jQuery, Angular, EmberJs, VueJs, Reactjs, and, of course, the well-known (notorious) NodeJs. All these tools use JavaScript as a base, and this has certainly contributed to the popularity of JavaScript.
Stackoverflow survey 2021 of the most popular technologies programming scripting and markup languages Font: https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-programming-scripting-and-markup-languages
So why is it that, even though JavaScript is more commonly used than Java, most SAP CPI developers seem to prefer to use Groovy script, the Java-like syntax language built for the Java platform? Undoubtedly, Groovy script is a good option, and is rich in resources for use in SAP CPI. However, I keep asking myself why developers use Groovy as a default. Why do they rarely use JavaScript in projects, or even share articles presenting solutions that use this fantastic language? In order to understand this, I had some discussions with fellow developers Jairo Canuto, Daniel Graversen, Mirko Longhi and Fatih Pense, all of whom have vast experience and domain knowledge on the subject. I asked why Groovy is more popular in the SAP CPI community.
According to Mr Jairo Canuto:
- Many programmers originate from Java.
- Around 2004 when the SAP Netweaver product was released, many Java developers started migrating to SAP for the purpose of to develop Webdynpro Java and also for integration with SAP Exchange Infrastructure – XI 2.0.
- This, in turn, uses the Eclipse IDE.
Given Groovy is a Java-like syntax language and, as Mr Canuto explained, many SAP developers were originally Java developers, this explains in part why Groovy is popular with SAP CPI developers.
Mr Daniel Graversen pointed out there a number of reasons that might explain the lack of popularity of Javascript for CPI:
- People coming from a small Java background do not need to change the way they have been coding.
- There are more libraries that can be added to the function.
- Most examples and standard content are in Java (a kind of Catch 22).
- It could be faster since it is more native to the CPI runtime.
- Uncertainty about how long JavaScript will be supported.
- The availability of developers who can support it.
According to Mr Mirko Longhi, an Italian developer:
- Groovy is more popular because it’s faster, it’s lighter and allows you to do more. By this he means you can write yourself an external .jar library and import it.
- Groovy is very versatile, you can use it to edit the payload as you like and also access log and CPI core instructions.
Indeed, the option to import Jar libs is a great facility. Also, the online tool is such a reliable resource, as it allows us to run tests on Groovy.
Mr Fatih Pense, said a number of reasons come to mind:
- SAP integration people are already familiar with Java. SAP PI/PO, which is still widely used, needs you to write Java mappings/functions from time to time.
- CPI itself is based on a Java framework.
- Working with XML is one of the powerful sides of Groovy (I was skeptical at first).
- Javascript works fine as a language (it might be missing new language changes, but it evolves fast), but you can’t use every package in NPM. This is not Node.js the runtime, it is just JS the language support.
Personally, I believe that another reason why JavaScript is not more popular with SAP CPI developers is the version of JavaScript supported by SAP CPI. Unfortunately, the most recent version of JavaScript that can be used in SAP CPI does not allow you to use modern standards, such as those in ECMA Script 6. This is not necessarily a big drawback, but if JavaScript ES6 were supported it would provide a number of enhancements that would make coding JavaScript simpler, including Arrow functions and improved array processing using methods such as Array.find() and Array.findIndex().
Have a look at the example below:
const nameStudents = [
{name: 'Grant', schoolId: 1, country: "Br", score: 10, age: 26},
{name: 'Tulio', schoolId: 3, country: "BR", score: 25, age: 22},
{name: 'Paolo', schoolId: 2, country: "IT", score: 48, age: 55}]
const schools = [
{id: 1, institution: 'IBM', active: true, since: 1950},
{id: 2, institution: 'SAP', active: true, since: 1950},
{id: 3, institution: 'TechM', active: false, since: 1950}]
//Return the SUM of students where the scores is an integer division or Age >=25
// -> From the result above, select where school is active
// -> double the score
// -> print SUM the values and students list
//old fashioned
var sum = 0;
var listAproval = [];
var output = {}
var listAprovalSchool = [];
for (var i = 0; i < nameStudents.length; i++) {
if (nameStudents[i].score % 2 === 0 || nameStudents[i].age >= 25) {
for (var j = 0; j < schools.length; j++) {
if (schools[j].id === nameStudents[i].schoolId && schools[j].active === true) {
sum = sum + nameStudents[i].score * 2;
listAproval.push({
'fullname': `${nameStudents[i].name} - ${nameStudents[i].country}`,
'yearBirthday': new Date().getFullYear() - nameStudents[i].age
})
}
}
}
}
output['sum'] = sum
output['studentList'] = listAproval
console.log(output)
//Using ECMAScript 2015
let students = nameStudents.filter(({score, age}) => score % 2 === 0 || age >= 25)
.map(({name, country, age, schoolId, score}) => {
let school = schools.find(({id, active}) => id === schoolId && active === true);
if (!school) return null;
return {
fullname: `${name} - ${country}`,
yearBirthday: new Date().getFullYear() - age,
score
};
}).filter(Boolean);
let sum = students.reduce((total, {score}) => total + score * 2, 0);
let output = {
sum,
studentList: students
};
console.log(output);From a personal point of view, I believe that SAP updates for the SAP BTP product will soon appear, and more modern JavaScript version standards, especially those defined by the TC39 Committee, will be implemented, as this organization releases the latest updates regarding JS annually.
Finally, the vast majority of interfaces developed with SAP CPI follow the SOAP standard, which favors the use of Groovy, since it brings a certain ease of processing XML through its parse patterns. However, we also cannot fail to notice that many of the non-SAP interfaces use the JSON standard, an acronym for JavaScript Object Notation, in which JS proves to be a more favorable and advantageous language to use.
My intention in writing this article is only to start a discussion about the use of Groovy and JavaScript in SAP CPI. It is not my intention to make performance comparisons between the two, as both languages have positives and negatives. However, it would be interesting to start seeing new articles about JavaScript. So, please join the discussion by leaving your comments about your experiences using JavaScript or Groovy with SAP CPI, which script you prefer, and why. Hopefully, by promoting such a discussion, we can learn from each other and expand our knowledge of both JavaScript and Groovy.
Hi Tulio,
Great post.
==
Minor remark to avoid confusion and allow for proper tagging of the article for wider reach, last year around this time, SAP announced to sunset of the "SAP Cloud Platform" product to avoid confusion with the then recently announced SAP Business Technology Platform (BTP) portfolio (broader in scope).
As a consequence, other products referencing the SAP Cloud Platform (SCP) brand were also renamed, e.g. SAP Cloud Platform Integration (CPI) into SAP Integration Suite.
Thank you Mr Denys.
Great blog Tulio. Keep writing the blog, they are so knowledgeable.
Thank you Ojavitaa.
Great article, Tulio!
Thank you Pedro Lucca.
Hi Tulio!
Thanks for gathering all the remarks from community experts, distilling the information, and sharing with the community! It makes it an alive and interesting discussion starter!
Also thanks for including my comments.
This topic was asked me by customers who want to evaluate their options. Now, I'm glad that there is an article that I can refer to!
Best regards,
Fatih Pense
Thank you my friend, Fatih!
Hi Tulio,
Thanks for bringing the interesting disucssion.
When I started the first reason to switch to groovy was we could use same syntax as java and it would work and as time progressed it was easy to adapt to groovy syntax.
Even most of the cases we were handling xml based paylaods it seems easier to handle XML parsers in Groovy.
thanks and regards,
Praveen T
Hi Praveen, thanks for your words.
Hi Tulio,
its an interesting topic. in CPI world groovy is ranked #1.
Reg, avinash
Thank you Mallashetty.
Hi Tulio,
great article that sum up many aspects.
I'd like to start using javascript, for many reason could be better, if only the version available in SCPI would be higher, allowing us to use new and not outdated functions
Thank you Mirko.
Hi Tulio,
Good one.
I guess 90% of the people who work in cpi are from sap po so they prefer Groovy than JavaScript as they used java in sap po.
People who work in cpi and pi/po are not good at programming. They know basic java/xslt programming, and that is good enough to deliver and support the project. If most of them are good, then we would be flooded with custom adapters and many more tools. No one would be selling customer adapter, I bet.
I am not sure, but it seems to me that only 5 to 10% are good at programming who are cpi/pi developers.
Thanks Marasamy for your comment.
I think it's fairly obvious that the Stack Overflow survey results aren't really representative of the enterprise software world. The survey even states "for most developers, programming is web programming". Yes, in the web world JavaScript reigns supreme, but much less so outside of it. But CPI developers who prefer JavaScript should absolutely go for it - and blog about it too!
Hi Morten, I'd like to go for javascript, but as I can see, the version in CPI doesn't allow me to use a lot of new things.
I remember once that I had to filter a Json, with the new javascript or importing libraries I can do it simply with ".filter" function, I cannot slow the iFlows only because I have to keep looping arrays and json object.
This is just the first example that come to mind.
Hi Mirko
That makes sense. Also, see my comment to Tulio below.
Regards,
Morten
Hi Mr Wittrock, it's a pleasure to hear from you and great to see that you are interested in sharing your thoughts on this discussion.
As I said in the article, I am not here to tell what language developers must use at SAP CPI, but to understand why many developers avoid to use JS in their projects or write about it.
You've said that is obvious that the Stack Overflow survey doesn't represent the real-world of enterprise software, and you can be right due the JS has undergone changes and become more robust only in recent years, but there is no doubt about its growth has been exponential and the abundance of threads over the Internet abording JS, I was just wondering why there are so few articles about it.
In the article, I mentioned that the version of JS is outdated, as Mr Mirko also commented; for instance, it is impossible to use new features from ES6 which are helpful.
Thank you.
Hi Tulio
It's definitely important to let SAP know, that there is developer interest in a more up to date JavaScript engine.
Regards,
Morten
As it has been rightly pointed out, JavaScript popularity originates historically from frontend development, and more recently, from Node.js based backend development. Assessment of JavaScript popularity done through the lens of a Java ecosystem in general and Java-based integration platforms in particular, evaluation of JavaScript adoption as a language of choice for scripts that are called out from the Java application (we shall keep in mind that SAP Cloud Integration is a Java-based service), will lead us to a different outcome as compared to the general context-agnostic IT assessment (based on TIOBE programming community index, or programming languages' popularity ranking based on GitHub or StackOverflow statistics, etc.).
I would like to take JavaScript / ECMAScript standard version that is currently supported by SAP Cloud Integration runtime, out of the equation in this comparison. Undoubtedly, inability to use latest and greatest features of the language impact the way how a developer can express and code the needed logic, and in certain cases, negatively impacts performance of a script, maintainability of a codebase. But we can evidence a similar situation with Groovy – SAP Cloud Integration doesn’t use the latest stable version of a Groovy language either: SAP Cloud Integration uses Groovy 2.4.x currently while Groovy 4 being the latest stable release. Consequently, some existing language features and APIs are not available for CPI developers when they develop Groovy scripts. A list of examples can be extended with versions of some core components that form SAP Cloud Integration runtime, too. This is a broader subject that is highly impacted by justification of migration efforts associated with the upgrade of each of these elements and its impacted dependencies, and accompanying compatibility, performance and stability issues that must be resolved to retain reliability and functionality (including its backward compatibility) of the overall service/product.
There are a few reasons why I personally prefer Groovy over JavaScript when developing scripts for SAP Cloud Integration – to name the most noteworthy in my judgment:
I deliberately don’t get into topics related to discussion of performance aspects of Groovy and JavaScript here not because I underestimate their importance, but because they might become quite controversial, and I doubt there is a clear winner here. I’m not aware of any studies or statements that collectively and unambiguously will draw a conclusion of a script engine for one of discussed languages permanently and generally outperforming its rival for another scripting language when being put in context of script invocations initiated by a Java platform. Moreover, performance measurements run against different script engines that implement support even for the same scripting language (for example, for JavaScript language – Nashorn which is the default script engine for JavaScript in the JVM implementation that is currently used by SAP Cloud Integration, and Graal.js which is a part of GraalVM, just in sake of an example), demonstrate drastic difference depending on particular use cases and scenarios. To make such performance comparisons more meaningful, we will have to base them on reproducible measurements done again specific set of scenarios, workload patterns, with well-defined runtime constraints and assumptions that are specific to defined integration use cases. Which in its turn will inevitably bring us to further discussions of synthetic and isolated performance measurement and benchmarking of the particular script executed by the specific script engine implementation versus script execution put under actual operating conditions of SAP Cloud Platform runtime that is occupied by concurrent and competing workloads. I tend to think that generalization here will be counter rational.
Hi Vadim, I really appreciate your comments. Cheers
Very interesting article.
Thanks for sharing Tulio!
Thank you Levy !
Hi Tulio!
Really great blog that summarizes important reasons / causes about why most developers are still using Groovy instead of Java.
Keep writing new good blogs like that my friend, it was a pleasure contribute and count on me to the new ones!
Thank you very much for your contribution to my blog post, Jairo.
Hi Tulio!
Nice stuff and good to see that someone has taken this topic out in open
Well in my perspective there are two primary reasons for this.
Personally I am big fan of java script but I always end up creating groovy in my CPI iFlows
Cheers,
Anuj
Hi Pandey!! Thank you so much for your comment. Cheers
Thanks Tulio for bringing up this discussion and the feedbacks. Hope we could use Javascript more freely specifically the DOM parser for xml payload
regards
binu jacob
Congratulations Tulio for the informations.
We need to know for which way SAP will go in the future.
NowaDays SAP show more about Groovy Script, but in the future everything can change.
The same way that SAP change the name of your products, It can change which is your favorite language in CPI.
Hi Neylon,
Thank you for your comment. I really appreciate your feedback!
Cheers
Here are the reasons why people might choose one language over the other in SAP CPI:
Familiarity: Some developers may have more experience and familiarity with JavaScript, and may feel more comfortable using it.
Performance: JavaScript is a highly optimized language and can perform certain tasks more quickly than Groovy.
Widely used: JavaScript is widely used and has a large community of developers, which makes it easier to find support and resources.
Standardization: JavaScript is a standardized language, which means that it has a defined syntax and behavior. This can make it easier to maintain and troubleshoot.
Interoperability: JavaScript can interact with a wide variety of technologies, making it a good choice for integration with other systems.
Ecosystem: JavaScript has a rich ecosystem of libraries, tools, and resources, which can make it easier to develop and maintain applications.
It's worth noting that Groovy also has its advantages and might be a better fit for certain projects or use cases, so the choice between the two languages ultimately depends on the specific needs and constraints of the project. ManageMyHealth
Hi James,
your comment is highly valued and greatly appreciated!
thanks
SAP Cloud Platform Integration (CPI) is SAP's cloud-based middleware that connects users' SAP ERP systems with third-party products. These products can be cloud based, on-premises, SAP, or non-SAP. The service allows real-time data exchange between these systems.
Drift Hunters