Skip to Content

The beta phase for our new SAP Gateway Demo system that was announced by  in his blog Netweaver Gateway Demo – ES5 now in Beta!  is now over and we can thus announce the availability of our new “production system” ES5.

As Jonathan already wrote we look forward to your feedback and encourage you to use our new system since ES4 will be shutdown in the future.

What’s new?

The new SAP Gateway System is based on SAP NetWeaver 751 and thus comes with several new features as opposed to the predecessor system ES4 which was based on SAP NetWeaver 740.

SAP Fiori Launchpad and SAP Fiori Reference apps

For all users we have configured SAP Fiori Launchpad where you will find four applications that have been deployed.

 

Launch the SAP Fiori Launchpad

 

Demo services for SAP Fiori development

You can use SAP Web IDE to develop SAP Fiori applications on top of the demo services that are provided in the SAP Gateway demo system.

SAP Fiori Sample Applications

As an example you will find OData services that allow you to create SAP applications based on SAP Fiori Sample Applications.

Approve Purchase Orders

A SAP Fiori Reference Application used to demonstrate the approval process
Oased on the EPM model This is a master-detail applicatiom

Shop

A SAP Fiori Reference Application used to demonstrate a shopping scenario on the EPM model This is a full screen application.

Manage Products

A SAP Fiori Reference Application used to demonstrate the creation and maintenance of product entities for the EPM model This app is Oased on Fiori Elements

Procurement Overview

A SAP Fiori Reference Application used to demonstrate an over,new ofthe EPM model. This app is based on the new SAP Fiori Elements Overview page.

Sample service GWSAMPLE_BASIC

There is also the well known basic sample service GWSAMPLE_BASIC available that provides you with a practical, working OData service with meaningful content that supports basic OData operations.

The following link would provide you a list of items of a sales order from the Enterprise Procurement demo data:

https://sapes5.sapdevcenter.com/sap/opu/odata/iwbep/GWSAMPLE_BASIC/SalesOrderSet?(%270500000001%27)/ToLineItems

You can find more information about the basic sample service in the SAP Online Documentation

SAP Online Documentation: Sample Service – Basic

OData V4 demo service

In ES5 there is now also a first demo service available that supports OData V4.

https://sapes5.sapdevcenter.com/sap/opu/odata4/sap/ze2e001/default/sap/ze2e001_salesorder/0001/$metadata

More details can be found in the following blog OData V4 code based implementation – Overview.

How to get access?

As with the predecessor system you have to sing up for an account in ES5. To do so simply follow this link:

Sign up for a demo account on ES5 here

After you have signed up for an account you can access the demo system in various ways:

SAP Web IDE

In your SAP Cloud Platform Cockpit you have to create a destination using the following data:

#
#Tue Dec 05 14:36:33 UTC 2017
Description=SAP Gateway Demo System
Type=HTTP
TrustAll=true
Authentication=NoAuthentication
WebIDEUsage=odata_abap, bsp_execute_abap, odata_gen
Name=ES5
WebIDEEnabled=true
CloudConnectorVersion=2
URL=https\://sapes5.sapdevcenter.com
ProxyType=Internet
sap-client=002
WebIDESystem=ES5

You can simply create a text file that contains the above mentioned data and import the destination as follows:

  1. Login to the SAP Cloud Server Cockpit
  2. Select your account
  3. Click Connectivity
  4. Click Destinations
  5. Click Import Destination
  6. Select your destination configuration file and click Open.

 

SAPGUI for HTML

Using this link SAPGUI for HTML access you can log on to the system using SAPGUI for HTML.You will see the following logon screen: Access is a restricted to read-only access for developers though. Reason is that otherwise the stability of this system could not be guranteed.

 

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Paul Hardy

    Mr. Andre,

    I am desperate to ask you a philosophical question about Gateway.  Another SAP employee was blogging about Gateway on the weekend, but it turns out there are many components inside SAP, all called Gateway, so i got confused and asked him about Gateway and he told me I had the wrong Gateway.

    So just to be clear, I am talking about the Gateway component where you define services using SEGW (at least for now) and they get exposed as ODATA. that sounds just like what you are talking about above. If, after reading my question, it turns out there is yet another component in SAP called Gateway, please point me in that direction.

    We have a customer portal where the user enters a sales order on their phone or laptop or whatever, and the JavaScript code on the device does a call to a Gateway service I wrote in SAP. It all works just fine, and we are on top of the indirect licencing thingy, so everything in the garden was rosy.

    Now we have a proposal for a generic middleware layer, all Microsoft based, taking in the HTTP call from the mobile device, in whatever country, working out dynamically the correct source system and connecting to it. All lovely and object oriented, several layers all abstracted from each other.

    The problem is the architecture calls for assorted Microsoft integration services connecting to the source systems. the one chosen to connect to SAP is from a company called Theobald software, which works by connecting to custom RFC function modules inside SAP.

    Now I don;t want to give up Gateway. The arguments I am facing in favour of RFC function modules instead of Gateway are as follows:-

    • it (RFC) works and it is easy
    • all the other source systems are contacted directly and contacting Gateway is contacting “middleware” instead of the actual source system, thus giving one source system special treatment instead of treating all source systems the same
    • the call to Gateway will introduce two more HTTP calls in addition to the original one from the device, thus negatively effecting performance, and making t more difficult to pinpoint any point of failure
    • Gateway cannot do an asynchronous call

    Now, I would like to tell me that these arguments are nonsense, and give me some cast iron reasons I can use to knock holes in the proposed plans. However if the above are valid arguments, please tell me that as well.I try to keep an open mind, and I have a lot of respect for the architect of the middle ware framework and how well designed it is from an abstract OO perspective. It is just this one little technical part of the pie I am concerned with.

    I have talked to lots of my fellow SAP Mentors about this, and the only argument I have thus far is a philosophical one in that Gateway is SAP’s future direction. Whilst I agree with this 100% it is not getting me very far at work as an argument. I need something more concrete.

    Cheersy Cheers

    Paul

     

    (0) 

Leave a Reply