Introduction
Last year I had the chance to speak at the SAP Inside Track Belgium in Antwerp about the SAP Cloud SDK and the efforts I discovered by using it in my projects.
I want to use the outcomes of my track with combined feedback I did receive to publish some more inspirations and examples about the SAP Cloud SDK (for javascript) because meanwhile I see the SAP Cloud SDK within their Virtual Data Model (VDM) as essential for every nodeJs (or java) projects on BTP!
Implementing nodeJs applications / microservices is the optimal way to realize required custom coding in context of SAP Cloud projects by not using no-code / low-code tools (e.g. CPI).
The most nodeJs applications I saw within SAP & BTP context had (node-)modules like "axios" in use to realize asynchronous REST HTTP requests to send to systems like S/4 HANA.
Using SAP Cloud SDK for these purposes does make life easier - especially the life of us, developers!
The SDK combined with described & structured oData REST APIs empower us to realize Virtual Data Models and simplify & speed up our implementations 🙂
What's a Virtual Data Modell
Data, for example on S/4 HANA, is stored in complex and abstract structures and tables. Therefore, in ABAP we did use the data-objects and models coming from the Data-Dictionary (DDIC) to deal with this complexity.
With capabilities of data-domains and data-types, we were able to know more about parameters used in structures.
So, for example we do know the "BUKRS" data-type has a specific max-length (4 chars) and can contain any characters.
These kinds of details, available on the SAP systems, we want to keep available.
Details like that are provided within oData REST APIs, who are using Entity Data Models (EDM) to represent these values (this is visible using $metadata entity on the oData API or by accessing APIs on the API Business Hub, where they share the EDMX file as well - check tab "API Specification" as example on the Business Partner API).
As HANA is using the Virtual Data Model (VDM) to reflect the abstract and complex structures of the EDM in semantically ways, we're going to do and use the same with the SAP Cloud SDK in our nodeJs typescript app (or within java applications, if you're interested in using java, check out this post by Henning Heitkoetter)
Because it does not make sense to throw away useful detailed information about parameters supplied in an oData API 😉
So, the (generated) VDM will be some object representation of our oData service, in typescript this is a type-safe client.
And why do we want to use it?
Beside some default capabilities, like interacting with the destination-service of the BTP, the key effort of using SAP Cloud SDK comes within using a VDM in a typescript nodeJs application, because it's about using a type-safe environment within our application.
It is really useful while developing the application themself. It does provide you a bunch of capabilities you'll love as a developer:
You will write less code (boilerplate)
You will speed up your implementation (due to existing types)
You will get warnings (e.g. for typos) while implementation / dev-time instead of while run-time
It's easy to generate these VDMs / type-safe clients by using EDMX (Metadata) files (or swagger files)
Enough text, show me what's in for me - Let's focus on that "type-safe" thing ...
Example Business Case: Fetch all Suppliers related to Company Code "DE01".
That's the standard "axios"-approach we know:
We do concatenate the URL to our S/4 system, with entity name, filter and expand functionalities. We're using "axios" to send the HTTP request to S/4 and receive unstructured json data in return.
The URL is a plain string, so typos will not be visible while dev-time and do occur instead while runtime.
The SDK approach:
We're using the VDM (here it's generated & provided by SAP - check this docu to "generate" it on your own) and do access the "supplierCompanyApi".
Within a "requestBuilder" we're going to fetch "getAll" entities within the filter we did add. At the end we do execute it against a destination we did fetch from BTP Destination-Service and receive a structured object from S/4.
This has been typed within seconds, because the VDM did generate a SDK-Client and we're able to implement within the type-safe environment!
The searchhelp (here it's on VS-Code) does show up existing properties of the "supplierCompanyApi" and allows us to select the correct one immediately:
Besides that, we do get warnings if we have some typos (here: missing underscore) within our coding:
This is possible due to the usage of the VDM! As the structured oData API is providing us details about available properties and their types.
More efforts please
Beside the effort of saving time by faster implementing our oData-requests using the VDM, there is more.
Maybe you did already identify the biggest effort of all of that from the screenshots above:
public async getCompanySuppliersAxios(companyCode: string):Promise<any>{vs.
public async getCompanySuppliers(companyCode: string):Promise<Array<vdmBuPa.SupplierCompany>>{It's about the returned type of the function!
The consumer of the first function "getCompanySuppliersAxios" does not know about what the function will return (beside the fact it's a promise). It could be anything.
The consumer can't use the effort coming out of types, as there are no types defined and related to the return of the function:
The consumer of the second function "getCompanySuppliers" does know what he can expect: An array of the entity "SupplierCompany" of the VDM "vdmBuPa".
So it does know about the type we do receive and therefore, the properties can get selected up via the searchhelp:
How to start using SAP Cloud SDK?
We saw some benefits of using a VDM within the SAP Cloud SDK.
But the SDK does provide us more capabilities:
Easy access to BTP services (most common: The BTP Destination Service; provide out-of-the-box support of destinations saved on the service and bound to the application)
Generate VDM type-safe clients for your oData API by using the EDMX / Metadata from the API within the EDMX-Generator
Generate VDM type-safe clients as well for openAPIs. Use a SWAGGER file within the openAPI-Generator to do so
Implement your first application within a VDM by following a tutorial (e.g. the Address-Manager)
Check out the "Getting Started" page of the SAP Cloud SDK
Conclusion
Within the Cloud SDK and their adoption of the Virtual Data Model, SAP is providing functionalities and capabilities to us developers to easy use the benefits of structured oData APIs.
In my last project we did set up more then 30 different VDM clients, which we do host on AzureDevOps as Artifacts (if you want so - it's like a "private npm"). We set up multiple CI/CD pipelines to automatically refresh VDMs if a related oData API got changed. These VDMs did not only point to S/4 HANA systems, they also got used within R/3 onPremise installations and CAP applications running on BTP.
This approach did help and speed up our implementation at the same level, as it did raise the quality of our application portfolio, who is consuming / using these VDMs. We were able to reduce a lot of bug appearances, as issues with oData APIs or type miss matches did appear already while implementation phase.
Based on many different backgrounds of skills, it can be a long and though way down the road to get to know javascript, nodeJs, typescript and the SAP Cloud SDK within VDMs. But it's worth it: Raising quality, saving time and it does make fun as well 🙂
Last but not least - Thanks to the team behind the SDK, I did raise some issues, questions or feature-improvement-ideas on the official github repository and I am really impressed by the speed and quality of responses I do receive.
- SAP Managed Tags:
1 Comment
