Last weeks there have been some interesting blog posts about the new Gateway tool to make life easier for developers: Gateway Productivity Accelerator(GPA).
With this Eclipse based tool you can model your OData services and use these models in the front-end tool you are using as well as in the back-end Gateway Service Builder. Front-end support of the GPA exists of php, iOS, HTML5 and Android toolkits. Back-end support is provided by the possibility to export the OData model in a format that the Gateway Service Builder can import.
There is not that much blog material on the Gateway Productivity Tool yet and therefore I was following the guidelines from the GPA Developer Guide, https://help.hana.ondemand.com/gateway_gwpa/pdf/SAP_NetWeaver_Gateway_Productivity_Accelerator_Dev_Guide_en.pdf, but this is a very l
arge document counting 270 pages. The documentation is therefore very extensive but there is also a lot of information that might have been skipped or is just not interesting. There is a lot of explanation on the Eclipse perspective and how to use each button and what all the options and possibilities are, you can search for it when it is needed.
I decided to make some screenshots and provide you with my first impressions. I have made an ODataModel from scratch but the
GPA is also capable of generating OData models using existing service metadata files, a service metadata URL and an existing ODatamodel which is already residing in an repository.
The first thing to do is install Eclipse Juno IDE for EE developers and install the SAP software according to this link:https://tools.hana.ondemand.com/#gateway. Open the new perspective OData and create an initial Project “MyFirstODataModel”. Within the project I have created an OData model called Banks, which is created with the template for an “Blank OData model”.
To start the modelling I have created an EntityType “Bank”. Creating this it generates a default entitySet named “BankSet” and a key property “BankId”. This default properties of the EntityType can be renamed by selecting it and pressing F2. Changing the entityType name will also change the defaultnames of the entitySet and entityId. Via the context menu or using right mouse click it is possible to extend the entityType with Sets, properties or navigation properties. An overview of an attribute in the modeller is given in the Properties View. In this view of a selected attribute’s properties, these properties can be seen and edited.
I created a second EntityType “Account” and now I want to create an association between these two EntityTypes. This can be very easiliy done by picking either Single of Bidirectional Association from menu and pick the two Entities you want to associate. If you want to create an self-association you can drag and the association line from the specific EntityType to itself. The default association is a 1:n association.
The GPA makes it easy to reuse existing EDMX artifacts by making it possible to reference to other EDMX Vocabularies. This can be done via a service URL or a service metadata file. The Referenced types are then also usable in the OData model editor.
Now I have created a very simple OData model and I want to export the created model to use it in the Gateway Service Builder in the SAP back-end. This can be very simple done by going to File -> Export and then choosing Odata Development -> OData Model. There is the option to export the model as a OData V2, OData V2 SAP Specific or OData V3 format. To get to know the exact differences in format, you can read this: http://www.odata.org/docs/. It is recommended to use the OData V2 or the OData V2 SAP Specific format when you want to use the file to import in the Gateway Service Builder, transaction SEGW.
Now I have exported my OData model this model can be used in the Gateway Service Builder to create your Gateway service. This part is not what I wanted to show you today but might be a next blogging topic.
I hope this short introduction will get you a jumpstart in using the Gateway Productivity Accelerator. I think SAP has made good progress by introducing the GPA. This enlarges the possibilities to do Gateway service development with a top-down approach which is the right way to go. Gateway development should start with modelling of your data instead of finding a way to fit your gateway service on existing function modules in the back-end. Although top-down development might not always be possible, I think the GPA makes it more easy and therefore hopefully it will be more and more used bu developers.