Enumeration of Gateway licensing

Last a colleague asked me about the license model of Gateway usage. As this was not the first time I got such request, and a clear answer is hard to find online, I decided to base a blog on the answer I provided my colleague. So I at least myself have a source to refer to in future requests... Mind you that I do not guarantee the answer to be future proof, as SAP already once changed the Gateway license model.

In very short, Gateway licensing is as follows:

1. Usage of Gateway to consume SAP data and functionality via Gateway Services (preferable REST, but SOAP although not SAP-recommended still supported), requires that the end-user has a Gateway User license.
2. If end-user is already a SAP business suite user, this now also includes the right to consume SAP data and functionality through Gateway services. This has actually changed from the initial Gateway license model. In the beginning you were required to purchase the Gateway User license on top of already paid business suite usage. SAP later recognized this as double-charging it's customer-base, and corrected this.
3. For new users, e.g. so-called casual users that have never 'seen' the SAP GUI and have no intention to ever use that, you need to purchase the Gateway User perpetual licence. Current list-price is 1,350 USD per user.
4. In case the new user is using Gateway indirect in context of another SAP product, e.g. Duet Enterprise or SAP Mobile, SAP provides the Gateway User License for Productivity Apps (GULPA). This license is restricted to using Gateway as part of the Duet Enterprise runtime flow or SAP Mobile product. List-price of this is set at USD 375.00, to my knowledge divided in 250 USD for Gateway usage, and 130 USD for Duet Enterprise.
5. In case of a volatile and continuous changing user-base with anonymous users, a typical example is that of webshop customers, SAP provides a transaction-based licence model: Gateway Consumer Access License. You purchase a 'bundle' of service calls that you are allowed to invoke and consume in a calendar year. Current stock price of a bundle of 75.000 service calls is USD 450.00.

GWPAM Rapid Deployment Service on SAP-Microsoft Unite site

Earlier I reported about our involvement in the new SAP product for direct availability of SAP data into Microsoft Office clients: SAP NetWeaver Gateway Productivity Accelerator for Microsoft, short GWPAM.

Based on the knowledge and experience that we have gained early on in applying GWPAM, we have worked out a Rapid Deployment Service for GWPAM. This RDS solution is recognized by the SAP Gateway product team, and published on the SAP-Microsoft Unite Partner Connection site.

In the Rapid Deployment Service, we combine our proven approach for successful implementation of SAP-Microsoft integration scenarios with GWPAM product knowledge. Central concepts in our approach are user-centric focus, UI-design via (preferable) clickable prototypes, integration architecture, and technical expertise with the Microsoft and SAP application platforms. Check out in case you're interested in easily bring SAP data into Microsoft based front-ends.

On close edge with SAP Gateway product development team

The SAP Fiori suite receives welcome confirmation from end-organisations. The concept of smaller productivity Apps for dedicated business scenarios, with a modern and user-friendly UI, is largely applauded in the SAP users market. The first wave started with 25 standard Apps targeting mainly at HCM and a bit of SRM, and SAP is continuously expanding on this suite to include more scenario's.

However, SAP alone cannot deliver Apps for all scenario's that may be relevant for individual organizations. The strategy is to augment the standard SAP Fiori suite with custom-build Apps. The end-users benefit as all the productivity Apps that a Fiori customer has installed (SAP standard + custom augmentations), have the same and familiar look&feel.

I've started on such a project to build a custom SAP Fiori-like App for Invoice Approvals, a step within the process running as a SAP workflow in the backend. The customer first consulted SAP to inquire whether such an App would be on the radar as standard Fiori App. Answer is no, and SAP's advice to customer was to hire us to build it custom for them.

The customer is (rightfully) very keen on security. One of their concerns is that the confidential invoice data may not remain behind on the device.
We do not use local data storage within the Invoice Approval App. But browsers could cache received data responses. To prevent that, I want to alter the response with 'No-Cache' directions:

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
…

When I could not find explanation how-to include the 'No-Cache' directions in the response of a Gateway REST service, I decided to consult a direct contact within the Gateway development team: the notorious Andre Fischer :-) The response on my request for help is a perfect example of the close collaboration of the Gateway development team with partners [playing] in the field. Not only did I receive an useful response within half an hour (!!). It turned out that Andre also on-the-spot created a page on SCN to share my question + his answer to benefit the larger Gateway development audience: How to Avoid Caching of Confidential Data.

Tip: Resolve from ‘Choose key from allowed namespace’ at Maintain Workflow Filter Settings

Part of the enablement of Gateway Workflow (and also of Duet Enterprise workflow, as it is a first-class subscriber of Gateway workflow), is to specify the workflow filter settings. When entering new entries in the OSP reports, the system may return the message ‘Choose the key from the allowed namespace’, with the Parameter ‘TASK’ value identified as faulty.

Strange as the value ‘TASK’ is selected from the optionlist of allowed values (others are: ALERTCAT, DELTA, and WORKFLOW_STEP). It occurred in our landscape, and I could not find anyway to avoid nor correct the indicated input error.

However, as it turns out this message is only a warning. You can ignore it to have your submitted entry successfully be added to the filter customization. Just click on the ‘Enter’ icon, and next ‘Save’.

NetWeaver Gateway Productivity Accelerator for Microsoft

SAP data direct in Microsoft Office clients

Flagship of the Duet Enterprise / Gateway product team is Duet Enterprise for Microsoft SharePoint and SAP. Customers are very satisfied with the functionality and capabilities provided by this integration product, and the demonstrated product stability. A frequently asked question is to provide this level of exposing SAP data + processes also for use in Microsoft applications beyond SharePoint. The product team has responded to this market demand. Last week at SAP TechEd 2013 in Las Vegas, SAP NetWeaver Gateway Productivity Accelerator for Microsoft has been launched, shortly referred to as GWPAM.

As participant in the Duet Enterprise Customer Engagement Initiative (CEI) program, I was involved from the early development stage of GWPAM (under the internal codename BoxX). On request of the Duet Enterprise product team I performed so-called Takt-Testing, and reported my technical and functional thoughts + findings. Good to see that aspects of my feedback - predominantly influenced by my own technical background as an .Net architect/developer - have actually made it within the final product.

Like it’s big brother, GWPAM is in essence an end-product for the IT organization. It is an integration framework that internal IT departments and SAP + Microsoft partners (the ecosystem) can utilize, to build their own scenarios in which SAP / Microsoft integration is an important architectural element. GWPAM provides a Microsoft Visual Studio AddIn that .Net developers can use to directly in their familiair integrated development environment, lookup SAP Gateway OData services. And generate proxies to the Gateway OData services with standard .Net code.
The first foreseen scenarios are Microsoft Office Add-In’s, to expose and integrate the SAP business data in the everyday used Microsoft Office clients. For example, SAP CRM customer data in the form of Outlook contacts, invoice approval requests as Outlook tasks, functional data management of SAP masterdata through Excel, BW report data rendered in PowerPoint, and submit SAP CATS timetracking directly from your Outlook Calendar ...

Source: Introducing... SAP NetWeaver Gateway Productivity Accelerator for Microsoft [Holger Bruchelt]

Like Duet Enterprise for SharePoint, GWPAM provides support for the typical and recurring plumping aspects of SAP/Microsoft integration: Connectivity, Single Sign-on, End-2-End monitoring, .Net development tooling, integration with SAP Solution Manager. GWPAM offers a complete SAP / Microsoft integration package.
As with Duet Enterprise, the two suppliers have their collective strength and market presence behind this new product offering. This is also a major distinction compared to the various proprietary connectors of smaller parties.

As SAP / Microsoft interoperability expert, I am enthousiast about the addition of GWPAM to the SAP / Microsoft integration spectrum. GWPAM enables to build a new category of functional scenarios for end-customers. Now also for organizations that do not have SharePoint in their application landscape, but do have Microsoft Office installed on the desktops. And want to utilize that familiar employee environment for user intuitive operation of SAP data and business processes.

Related information:

• Introducing... SAP NetWeaver Gateway Productivity Accelerator for Microsoft
• SAP GWPAM Demo: Appointment Project Template - YouTube
• SAP GWPAM Demo: Add a Custom Value Help - YouTube

SAP Fiori deployment in our landscape

A longer and bumpy road, but eventually with a satisfying end-result.

At The Next View we have an own sandbox landscape in which we a.o. evaluate latest software products from SAP and Microsoft. We have for instance SAP NetWeaver Gateway installed upto the latest service pack sp7, and Duet Enterprise for the interoperability between SharePoint and SAP business suites. The arrival of SAP Fiori means another standard SAP application that we want to include in our landscape.

So I set out to achieve this. At first I checked out information written elsewhere on SAP Fiori deployment. The SCN postings “Architecting an SAP Fiori deployment” and “ “SAP Fiori Style Application Architecture Options” are recommendent readings. Next I studied the SAP Fiori Installation and Configuration guide, and determined what installation steps where needed in our landscape. The Fiori architecture namely imposes several prerequisites on your landscape, the most important ones being the presence of SAP ECC, SAP NetWeaver Gateway, and SAPUI5. The first 2 where already present in our landscape, SAPUI5 not. As SAPUI5 sets out to be a predominant part of the future of new SAP developments, this on itself is a welcome addition to our landscape.

In addition, also a multitude of SAP Notes must be applied, both in SAP ECC as in the Gateway system. Note that it is possible to install Gateway on same SAP system as ECC. In our landscape we have conformed to the SAP recommended infra architecture, and deployed Gateway on a dedicated application server isolated from the business applications.

The installation of the SAP notes, although time-consuming, went relatively straightforward. The real challenge (or rather problem, but lets keep up a positive attitude) was with installing SAPUI5. The challenge is not related to the software package itself, but to the installation approach that SAP mandates for it. Effectively it requires you to have Solution Manager present in your landscape. And let this be something that we currently not have yet in our sandbox landscape. The deployment of SAPUI5 requires Solution Manager for 2 aspects:

1. One is to be able to get your hands on the software package. SAPUI5 cannot be directly downloaded from SAP Support Portal / Download Center, but needs to be downloaded via Solution Manager. However, as SAP is not living under a rock, SAP does recognize that not all of their customers and prospects have Solution Manager available. As a gesture it is possible to request approval of software downloads, through issuing an OSS Message on component SV-SMG-MAI-APR. It merely only costs you some extra elapse time, but unless requested in the weekend (…), you typically get the approval consent within a few hours.
2. The second aspect gave me much more headache. When I tried to install the SAPUI5 packages in transaction SAINT, I was confronted with the message that a 'stack.xml' is required to install the SAPUI5 packages. A 'stack.xml'? Well, this in concept is a structural receipt for installing a certain SAP software package (here SAPUI5) in your own specific landscape. And such a software plus environment specific stack.xml is generated specific for your own landscape through…. Solution Manager. So I appeared stuck, as I had no clue how to make up such a stack.xml (manually) without the availability of Solution Manager. But when in trouble, you become the most creative ☺ As it turned out, a colleague had just installed SAPUI5 in another landscape, and he was kindly enough to share their stack.xml with me. Next I modified that stack.xml – replaced the SAP system id with ours, host name with ours, outcommenting parts that reported errors – until finally SAINT was willing to accept and process it. Mind you, this costed me 'some' spare time.

With SAPUI5 installed in our landscape, finally the installation of SAP Fiori Apps could start. In my opinion, SAP has made this unnecessary complex. It is not possible to install the SAP Fiori Suite at once, but you need to install it per App. And to make it even more time-consuming, each App consists of a data provider part on the business application, and a UI part on the SAPUI5 system. And lastly, per App there are already multiple support packages released; and the recommendation is to upgrade per Fiori App upto the latest support package. In general, the deployment of the SAP Fiori Apps, although thus time-consuming, goes smooth. However, when installing the upgrades / support packages, I found myself in a blocking issue within transaction SPAM: Field Z_PRS_BILL_FLAG in table SRA002_S_TIMEENTRYDF is specified twice. I posted the issue on forum ‘SAP for Mobile’, but before receiving valuable help, together with a colleague found a way myself to get out of the halted situation in SPAM.

To conclude, following are prerequisites for a successful Fiori installation:

• SAP business suite in your landscape with standard processes (in a sandbox environment, standard IDES will suffice)
• SAP_ALL authorization
• SAP developer key
• Authorization to register SAP objects, this is required for multiple of the required SAP Notes
• Strongly preferred: Solution Manager
• But if not available: creativity and minimal a template stack.xml
• Perseverance
• Time and patience; the amount is strongly determined by the initial state of your landscape. It makes a lot of differences whether or not you have already SAP NetWeaver Gateway and SAPUI5 installed. Only in case both are present, you can achieve a Fiori deployment within a day; if not it will typically cost you some additional days.

And learned lesson: The installation manual is not always clear, and at places even incorrect. In particular: don’t loose time to get your hands on the so-called component JSON-IWFND. We could not find it, so I consulted guru Andre Fischer. He responded that the sentence as written in the installation guide was misleading and thus erroneous: there is no such component.

But all-in-all, it’s the endresult that counts. And I’m very satisfied + proud that we now have SAP Fiori Apps available and operational in our own landscape.

Position of SAP NetWeaver Gateway versus SAP PI

With the advent of SAP NetWeaver Gateway 2.0 as standard SAP integration framework, the question arises what the positioning is towards SAP PI/PO, the other SAP integration approach. The question can be answerred from multiple viewpoints.

Business viewpoint

SAP introduced Gateway to address the strong and growing business demand for mobile access into the SAP business suites. SAP NetWeaver Gateway provides for mass consumption of SAP business data and functionality in your existing SAP Business Suite systems. The target audience for SAP NetWeaver Gateway applications is a group known as Occasional Platform Users (OPU). Gateway is designed to optimal facilitate people-centric applications. It is a lightweight framework, easy to develop services as well as consume them; and therefore allows short windows of [commercial] opportunities.

SAP NetWeaver Process Integration (SAP NetWeaver PI) is a comprehensive SOA middleware platform focused on A2A (Application-2-Application) and B2B (Business-2-Business) integration scenarios. PI provides SAP customers a SOA foundation to manage their SOA landscape and SOA development and deployment lifecycle. The scenarios are often executed autonomous, without direct involvement of ‘an user’.

Implementation of PI scenarios involves a lot of different aspects and complexities. As inherent consequence, it takes months before a new or modified scenario can be brought (desigend, engineered, tested and validated) into production.

Architectural viewpoint

SAP PI is foremost an ESB product. It is a separate product to enable integration of heterogenous landscapes, including but not limited to SAP only.

PI is intended as an enterprise integration broker. It enables multiple consumption and integration patterns, whether they be system-to-system interaction, business to business interaction, or simple consumption of backend systems via various interaction channels. It uses an adapter framework for connectivity into the various landscapes and technologies. Note that this is the common approach in ESB land. For instance, also Tibco and Microsoft BizTalk apply this. Through these adapters, multiple connectivity manners are possible: message based, web service calls, IDoc, JCo, JMS.

PI supports both synchronous and asynchronous invocation models. In case of the latter, reliable message-delivery is guaranteed.

SAP positions PI also as one of the parts of SAP PO (Process Orchestration), together with SAP BPM (Business Process Management) and SAP BRM (Business Rules Management). PO supports the orchestration of message exchanges and service calls via a BPMN- based process engine. PI enables herein the statefull handling of integration-centric processes, relying on standard integration patterns to support more sophisticated scenarios such as collecting and aggregating messages or bringing messages in the right order.

NetWeaver Gateway is the point of access into SAP Business Suite data and functionality. It’s single role is to service enable the SAP business applications to outside world, for stateless user-centric scenarios. This is direct/synchronous invocation, not messaging/asynchronous. Gateway uses the de-facto standard market protocol of REST and OData (ATOM + JSON) for simple and fast web service interface, relying on natural request/response mechanisms.

Gateway is aware of SAP internals, but hides them to the outside. To achieve optimal fast performance, Gateway directly invokes via SAP proprietary protocols the BAPIs and RFC of the business applications. There is no messaging layer in between, minimal extra time added in the ‘Gateway’ layer.

Gateway does not give access to non-SAP systems (at least not directly).

System viewpoint

Gateway is hosted on the NetWeaver ABAP stack. Initially it is deployed as Add-On to NetWeaver. As of NW 7.40 it will be an integral part of the NetWeaver ABAP stack.

SAP PI is a product on its own, deployed in the infra landscape of SAP customers. Prior to version 7.3, PI is hosted on a dual stack of NetWeaver Java and NetWeaver ABAP servers. Starting with PI 7.3 only the Java stack is required. From these NetWeaver servers, SAP PI is loosely coupled to the backend(s) - SAP and not-SAP. PI thus requires separate NetWeaver servers (minimal for the Java stack) in the landscape, in addition to the ABAP server(s) for the SAP business suites.

Development viewpoint

When you talk about service enabling the SAP landscape, you must be aware that you also talk about 2 different types of development. On the one side you need to provision the services within your SAP landscape, on the other side you consume these services – and this is not necessary within SAP context. Stronger, it typically will not be, in nowadays of Mobile and Web applications. Consumption is mostly done within iOS, .NET, Android, PHP, Force.com, HTML5, and also SAPUI5 context. The non-SAP developers do not want to care about the intrinsics of SAP internals, but just consume the data + functionalities in a standards-based way.

Consuming SAP PI services is very SAP specific; as developer you are made and have to be aware of the SAP intrinsics. Although SAP PI provides SOAP based Enterprise Services; reality forces to admit that they are still very much ‘SAP-aware’. You cannot feasible integrate with PI services without knowing about the SAP system behind. At minimal the data structure is SAP specific, and often also the processing model.

Gateway consumption instead also (or even more) aims at non-SAP developers; in that distinction you do not want to be aware of how SAP internally works, and its datastructures. Gateway applies a more lightweight approach to achieve this; and conforms to REST / OData as standards-based approach. It is able to do that because the focus of Gateway is much smaller as that of PI. Basically Gateway aims to expose SAP data to the outside world. And this perfectly matches with REST, the ‘ODBC protocol of the web’.

REST / OData can be consumed within any technology, and is supported in the common IDEs (Integrated Development Environments): Eclipse, Visual Studio and Xcode. To facilitate even more, SAP delivers a Productivity Accelerator to easily consume Gateway services in iOS, .NET or Java context.

To ease and accelerate development of Gateway services, SAP provides design-time tools to generate OData (or Generic / SOAP, but this is actively deprecated) services based from the existing SAP business objects in the SAP backend system. PI provides graphical mapping + transformation tools to map the data format of the integrated backend system into the external provided datamodel.

Note that to build both the ES Services as Gateway Services; you must have good knowledge of the disclosed SAP business objects.

Miscellaneous pointers

• SAP NetWeaver Gateway and SAP NetWeaver PI are complementary products
• Gateway is not a replacement for SAP Netweaver PI and eSOA services/ESB's
• Both SAP NetWeaver Gateway and SAP NetWeaver Process Integration can provision RESTful services to SAP backend applications (PI via the Advantco REST adapter)

Conclusive words

Gateway is recommended for user-centric applications. Use Gateway when there is a need for synchronous access to business objects of an SAP Business Suite system.

Use Process Integration when general purpose integration is needed, involving disparate systems and applications requiring asynchronous and synchronous services involving SAP and non-SAP applications and systems.

SAP lacks an official paper / statement regarding Gateway versus PI, but you can derive some of the positioning from their actual actions. SAP is using more and more SAPUI5 as lightweight front-end technology, with Fiori as evident latest example. In all published SAPUI5 examples, SAP applies Gateway for the integration into SAP landscape.

SAP Virtual Events hosted a one-hour session addressing the topic ‘SAP PI and Gateway – When to use what’. You can watch it here.