Why not use JavaScript instead of Groovy script in SAP CPI

[tuliovargas]

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-scripti...

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, mlonghi-altea 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 mlonghi-altea, 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.

[dvankempen]

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).

• A Robust Platform for RISE with SAP | January 27, 2021 by Juergen Mueller

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.

• community.sap.com/topics/integration-suite

 

[ojasvitaa]

Great blog Tulio. Keep writing the blog, they are so knowledgeable.

[pedro_lucca]

Great article, Tulio!

[fatihpense]

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

[former_member1924]

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

 

[avinash_mallashetty_scpla]

Hi Tulio,

its an interesting topic. in CPI world groovy is ranked #1.

Reg, avinash

[Mirko_Longhi]

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

[Muniyappan]

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.

[MortenWittrock]

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!

[Mirko_Longhi]

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.

[tuliovargas]

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.

[tuliovargas]

Thank you Mr Denys.

[tuliovargas]

Thank you Ojavitaa.

[tuliovargas]

Thank you my friend, Fatih!

[tuliovargas]

Hi Praveen, thanks for your words.

[tuliovargas]

Thank you Pedro Lucca.

[tuliovargas]

Thank you Mallashetty.

[tuliovargas]

Thank you Mirko.

[tuliovargas]

Thanks Marasamy for your comment.

[vadimklimov]

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:

• An already alluded gentle learning curve for those with background in a Java language (or some other JVM language). Although SAP Cloud Integration is not based on the same technology stack as SAP Process Integration / Process Orchestration (there are some borrowed components, but there are very few of those), as it has been mentioned already, a substantial number of CPI developers have prior experience with PI/PO, and their knowledge of Java becomes handy here. Moreover, given that SAP Cloud Integration is based on Java, further investment in learning of some relevant parts of a Java ecosystem pays off.
• A Groovy language allows usage of both dynamic and static typing, even mixing them within the single script. This provides us with flexibility where we need it (for example, when parsing XML or JSON payloads and further accessing nested nodes) and benefit from type safety in a great variety of other use cases where we need to be more strict and have a higher clarity about an accessed object type to benefit from codebase readability and supportability, better predictability of behaviour at runtime, ability to use auto-completion features offered by an IDE and gain more benefits from using static code analyzers in a quality assurance pipeline. In a JavaScript world, it is likely that we will need to approach and utilize TypeScript, should we want to achieve the same goal of type safety. Correspondingly, this will necessitate transpiling of the developed TypeScript code into JavaScript code before we can use it in SAP Cloud Integration - a routine, but a mandatory step.
• A higher transparency when accessing Java classes. This is not about interoperability with Java runtime – both Groovy and JavaScript scripts are executed by SAP Cloud Integration runtime with the help of corresponding script engines using a uniform and scripting language neutral Java Scripting API (JSR 223 / Scripting for the Java Platform), hence, we don’t expect any preference of one scripting language over another to be imposed and enforced by SAP Cloud Integration runtime. This is about the degree of seamlessness that developers experience when being in need to use Java classes in a script.

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.

[former_member623754]

Very interesting article.

Thanks for sharing Tulio!

[tuliovargas]

Thank you Levy !

[tuliovargas]

Hi Vadim, I really appreciate your comments. Cheers

[JairoCanuto]

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!

[MortenWittrock]

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

[MortenWittrock]

Hi Mirko

That makes sense. Also, see my comment to Tulio below.

Regards,

Morten

[pandey_anuj]

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.

1. CPI has camel foundation which comes from a JAVA technology family and goory is also from the same family so it is an usual suspect for compatibility reasons.
2. SAP integration developer community is not an open source community. It is kind of an opiniated framework where SAP has a broader stake to cultivate the developer mindset and paradigms. For many obvious reasons SAP has been promoting groovy since the beginning of the product so it is obvious to see groovy as standard choice of scripting  in CPI.

Personally I am big fan of java script but I always end up creating  groovy in my CPI iFlows

Cheers,

Anuj

[tuliovargas]

Thank you very much for your contribution to my blog post, Jairo.

[tuliovargas]

Hi Pandey!! Thank you so much for your comment. Cheers

[Binu_Jacob]

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

[neylonSilva]

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.

 

[former_member840391]

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

 

[tuliovargas]

Hi Neylon,
Thank you for your comment. I really appreciate your feedback!

 

Cheers

[tuliovargas]

Hi James,

your comment is highly valued and greatly appreciated!

 

thanks

[former_member850371]

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

[Lionel_Hu]

Hello Tulio,

Thanks to share those information and thoughts.

I did some research on my own and here is my five cents:

1. Basically CPI is a middleware that runs on top of Tomcat. So it's natively Java supported.
2. Based on official help document from SAP, the Javascript engine that was used on CPI is JavaScript Engine (Rhino) 1.7 R4. (Source: https://help.sap.com/docs/cloud-integration/sap-cloud-integration/define-local-script-step)
3. Rhino is actually just an implementation of JavaScript that written by Java code. (Source: https://github.com/mozilla/rhino) 
4. Unfortunately Rhino implementation is not a full functional JavaScript like in the browser. https://mozilla.github.io/rhino/compat/engines.html)
5. The native XML DOM based DOMParser is not available in this incomplete JS implementation. However you can use E4X object to manipulate the XML content.

I think that is the reason why the JS scripting is not that popular in CPI scripting world. The main battlefield for JS is still with frontend.

Best Regards
Lionel

[tuliovargas]

Well done