With the release of S/4HANA Cloud SDK 1.10.0 in April, SAP released a new tool called Virtual Data Model (VDM) Generator for OData. With this tool you can generate java classes from your own OData Service, which follows the same logic as SAP Virtual Data Model (VDM) services provided in the SDK. To generate readable java code, the VDM Generator reads the OData metadata file (EDMX) and uses the sap:label of for the class and attribute names. This works great when the sap:labels are available and the label values are valid names without special characters. Unfortunately in my project this wasn’t the case. We can use the fallback option --use-odata-names to create the java classes, but this will provide ugly and no readable names for our java code. This was not preferable and we looked for a better solution.
Our Project
We are a SAP partner and build a side-by-side solution with the S/HANA Cloud SDK on the SAP Cloud Platform that interfaces with odata services on the S/4HANA Public Cloud. These odata services are generated out of Custom Build Objects, which are built with the extension tools of the S/4HANA In-App.
Our Experiences
In the metadata of these odata services we found duplicate sap:label values within properties of entity types. Some of them where created by the In-App framework, uuid and partner_uuid will get the same sap:label names by the framework and associated text fields for localization will be having the same sap:label as it source. For others, we create them by giving labels in the CBO the same name. Or we use special characters like commas or abbreviate names including dots in our CBO labels. Some of them even don’t have a label because we don’t need the label on the UI. This is no problem for the CBO, the generated UI and the generated service. The metadata of the generated service is still valid but the VDM Generator expected unique sap:label names within a entity type. The VDM Generator doesn’t expect non-supported characters for java names and can not handle empty sap:label value. We saw all these situations happen in our project.
Our Solution
To solve this issue we need to modify the sap:label values but it is not possible for customers/partners to modify the OData metadata in the backend due the restricted development possibilities and automated generated services using the In-App framework in S4HPC. Because the VDM Generator is closed source, a solution must be found in modifying the generated OData metadata file (EDMX file) that is used as an input for the VDM Generator.
After a couple of manual modifications, we found out that this will not work. It cost the team a lot of time and we must work precisely else the EDMX was corrupted.
For this reason we build the EDMX Label Builder, which can do most of the work and solving the gap between S/4HANA automatic generated OData services and VDM Generator of S/4HANA Cloud SDK. The tool will be able to generate a properties file with can be modified by the user. The tool can be used to check the new properties file for inconsistency and will be used to generate a modified consistent EDMX file for the VDM generator.
In my next blog I will explain how the EDMX Label Builder will work more in-depth.
We share, Try it out
If you want to try it out yourself, you can download the EDMX Label Builder tool. The binary code is licensed under the Apache license 2.0. After downloading you can use the command: java -jar edmx-sap-label-builder-1.0.4.jar -h -v -r to get more information.
If you want to know more about SAP S/4HANA Cloud SDK you can go to this community page. On the release tab you can go to the release notes where you can find the latest version of the VDM Generator.
- SAP Managed Tags:
