Olaf Pohlmann
Read all my blogs
SAP Netweaver Gateway is (yet another) solution from SAP to expose business information and functionality to the outside world. But why do you want to use it if already you can build your own REST services or create webservices?
Earlier this year we installed Netweaver Gateway on one of our demo systems and I had a first look at it. As a developer I wasn’t very enthusiastic about the development environment that was shipped at that time. The last TechEd in Madrid provided a nice opportunity to have a closer look at the product and what the latest version has to offer.
The central access point is the Service Builder (transaction SEGW). Here you can create the Entity Data Model.
Gateway uses the OData protocol to expose this Entity Data Model and this comes with build in support for metadata definitions and a powerful query language. For instance a query to retrieve all business partners or just one looks like:
GET ~/BusinessPartners
GET ~/BusinessPartners(‘0100000000′)
Navigation to the corresponding sales orders of a specific business partner can be done with the following addition:
GET ~/BusinessPartners(‘0100000000′)/SalesOrders
An example of the output (in JSON format) of this call is:
Another feature is paging which can be used to limit the data that is sent across the wire:
The developer in the SAP backend has to implement to so called CRUD methods: create, read (and query), update and delete. An interesting remark was made during one of the TechEd sessions about paging: although the client receives limited data on the server the whole query result is retrieved first, then filtered and sent back.
Furthermore SAP NetWeaver Gateway is supporting the Code-free generation of OData Services based on frameworks including the, for CRM interesting, Business Object Layer (BOL/GenIL). Other features include XML or JSON support, monitoring, test tool, performance trace en logging.
To come back to the question of why would you want to use Netweaver Gateway, it has some great benefits:
- It places a conceptual data model on top of REST services
- making it possible to retrieve meta data on this model as well
- and by making it available through the OData protocol the SAP data is made available in a standardized way
- and therefore making it easy for other systems and devices to consume data without any knowledge of an SAP system’s internal workings
Receive our weekly blog by email?
Subscribe here:
