Wednesday, November 6, 2013
Monday, October 28, 2013
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 ...
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.
Friday, October 25, 2013
- 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.
- 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.
- 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
- 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.
Sunday, June 30, 2013
Business viewpointSAP 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 viewpointSAP 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 viewpointGateway 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.
Development viewpointWhen 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.
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.
- 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 wordsGateway 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.
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.
Friday, May 31, 2013
- I was surprised that still a large group of SAP developers do not really know [of] SAP NetWeaver Gateway;
- As of NetWeaver 7.40, Gateway is an integral part, no longer deployed as add-on;
- Gateway as platform stabilizes. It's now on Gateway 2.0 SP6, with SP7 expected in July. With that, the platform is mature and stable; and far less need for continuous new updates / deployments;
- Change in Gateway licensing: for each SAP named user in the backend, Gateway [usage] is free-of-charge;
- Focus of the Gateway Product team (development) is now on Gateway-as-a-Service aka in the cloud. This beholds the GW-HUB; GW-backend will (have to) remain on-premisse;
- GW-HUB can co-operate with a lower version GW-backend. This is of importance in case of deploying GW-HUB on a dedicated system, and from there connecting to / exposing the SAP business systems in your landscape. New Gateway developments / features are largely focussed on the GW-HUB level (Gateway-as-a-Service as a clear example), GW-backend on the other hand is relatively 'out-engineered'. The downwards compatibility enables end-organizations to update the GW-HUB in case of a new version / feature set on the dedicated gateway server [which has only a technical / integration role; it does not contain business functionality], without necessity to also roll-out a system update on the NetWeaver servers that do service business capabilities [and for which the business is rightfully reluctant towards changes and thus downtimes];
- Gateway Client is not only of usage for us / Gateway Service developers; but also for SAP Support. It enables SAP Support to execute and examine the behavior of [custom] Gateway Services via the already in-place SAP GUI logon. No need to provide SAP Support with access to Gateway Services on http / network level;
- When you test/execute Gateway service directly from a browser (e.g. Internet Explorer), use QueryString '?sap-ds-debug=true' to render the received response as HTTP page, and inspect the request + response [headers, cookies, body];
- For consuming Gateway Services within Microsoft context, Andre told me that Gateway can now utilize Kerberos Single Sign-On, through SPNego. Prerequisites are that the backend is on NetWeaver 7.31 or later, and that the company has SAP NW SSO 2.0 license.
Wednesday, May 29, 2013
Wednesday, January 2, 2013
Conclusions / Important lessons learned
- Standard Gateway WFService can be used to expose SAP workflow tasks with user involvement, to non-SAP front-end
- The different components of SAP Mobile Platform are all still new, with minimal to no references, incomplete and often outdated/incorrect documentation, no best practices yet, referential architectures and so on
- Mobility platforms and technologies are evolving fast; in general and in particular this also holds for SAP Mobile Platform
- We actually needed the latest versions of Gateway 2.0 (SP4 or later) and SUP (2.1.5) to successfully complete the Manager Task-Productivity App
- The current state of the platforms and technologies is sufficient, but does require us to apply some workarounds and accept some sub-optimal execution.
- Pull architecure is recommended for Gateway OData based App
- User-centric Design is key to deliver an App that the end-users are actually willing to use
- Workflow Extension Points (BAdI) enable to plug-in into the Gateway Workflow Service behaviour to augment with specific required behavior. E.g. retrieve workflow-specific additional data, complete ActivityTask iso the standard support UserDecision task.
- The manual user tasks (human interactions points) of SAP Business Suite workflows can be exposed outside boundaries of SAP without any modification in the SAP workflow.
Architecture decision: Pull or Push?
- Pull: Consumer requests the data from SAP
- Push: SAP Business Suite activily propagates the SAP data to any interested consumer.