Sunday, December 9, 2012

SAP NetWeaver Gateway reading list

SAP employees published 2 great SAP Gateway articles:
  • Chris Whealy published a Technical Brief; which serves both as conceptual introduction as well as positioning of SAP NetWeaver Gateway;
  • Andre Fischer published an article explaining SSO-authentication from outside to SAP NetWeaver Gateway (services), and what options are applicable for different context (intranet/extranet, application type).

Wednesday, October 24, 2012

Preserve X-CSRF-Token requires SUP 2.1.3

At customer we are conducting an innovation project to experience and validate the applicability of SAP NetWeaver Gateway and Sybase Unwired Platform (SUP) for exposing SAP workflow tasks management to mobile devices. The App has 2 integration dataflows with SAP backend:
  1. Retrieve the list of open tasks for logged-on user
  2. And per task, propagate task decision to complete the SAP workflow
The integration App - SAP Backend is achieved via REST and OData; which is stateless. To protect against Cross-Site Request Forgery attacks, SAP Gateway requires that data modifying requests include a valid X-CSRF-Token in the header. The token value must first be retrieved through HTTP Fetch via a non-modifying request, and can then in this session be used for subsequent modifying requests.
This approach worked correct when initially SUP excluded, and with requests direct invoked against SAP NetWeaver Gateway. Upon including SUP in the system landscape, we received error '403:Forbidden/Location'. Through HTTP sniffing I detected that the SAP session was not maintained over multiple http requests originating from SUP context. SAP Support analysis on the submitted OSS Ticket identified the inability to preserve the complete session cookie as a problem in the SUP 2.1.1 OData layer, and advised us to upgrade to SUP 2.1.3. This indeed resolved the issue.

Sunday, October 21, 2012

What to do with 'legacy' Generic channel objects?

In the initial releases of Gateway, the OData channel was not supported. All development was done on basis of the Generic channel; resulting in creation of GenIl and GSDO objects. As of GW 2.0 SP3, OData is included and now is - following the interoperability market - the preferred choice to unclose SAP data to outside SAP. A question is what to do with the 'legacy' of Generic channel developed scenario's. There are basically 3 options
  • Leave as is; GW 2.0 remains to support both runtime and design-time of Generic Channel. If the custom developed scenario is stable with no or minimal maintenance effort; there is no real reason to change;
  • Manual migrate: build again, now as OData services. This is the 'green sheet' approach; from IT architecture and maintenance perspective probably to be preferred, but hard to explain and convince the budget stakeholders;
  • Automatic migrate; transform GenIl objects into OData services. If required to migrate to OData services - to facilitate additional consumers, e.g. mobility -, but you will or may not afford to start from scratch; this might be a viable approach with short timeframe.

Saturday, October 6, 2012

Gateway troubleshooting tools

Friday, September 28, 2012

Gateway Generic Channel does not allow to change GSDO system alias

In the initial Duet Enterprise implementation + configuration in Development/Test/Acceptance/Production landscape, SAP BASIS applied the customer directive to use environment-specific names for system aliasses. When we transported the first Gateway models from development environment to test, we however encountered that this is not a workable configuration. SAP Gateway does allow you to associate generated GSDO types with another runtime system alias (via transaction SPRO / Gateway / Generic Channel / Assign GSDO Group). However, afterwards it is then no longer possible to regenerate the Gateway models!
In the SAP implementation methodology of customer, it is prescribed that Gateway model specification is done only within development system, and via SAP transport mechanisme the generated Gateway models are propagated upto the production landscape. However, this principle does not apply for the transition between Build and Run landscapes. Within the Run environment, it must be possible to alter and regenerate a CTS+ imported Gateway DataModel. Afterwards changing the associated runtime system aliasses of GSDO types is thus not viable.
Practical Duet Enterprise recommendation is therefore to apply generic/environment-indepedent names for the system aliasses that are referred in Gateway DataModels. Within the specific landscapes, the system aliasses are then configured with environment specific RFC connections. Additional benefit of this approach is that implementation of Gateway Models throughout the SAP landscape is freed from the manual step to modify for all of the transported GSDO types the system alias.
Update (Oct 4th, 2012):
We experienced another issue with GSDO types of which the system alias is altered: The metadata of the Gateway / Duet Enterprise webservice generated via the BDC Publisher has become invalid. This effect is not direct visible: the service still functions, both through transaction SProxy as for invocation from SharePoint through Duet Enterprise. We noticed the effect when we tried to re-import the generated BDC Model into SharePoint BCS, and BCS validates the model by trying to access the WSDL metadata of the Duet Enterprise webservice. This returned an error from SAP Gateway system: No data for binding key "53414....". We next received the same error when accessing in browser the BDC Model property-value WcfMexDocumentUrl. The effect manifestated itself for all Business Scenarios that access a GSDO type of which the system alias had been altered. Problem is fixed by regenerating each of the involved Business Scenarios in the BDC Publisher. As result internal in Gateway system the WSDL metadata administration of the webservice is newly derived and administrated; the exported BDC Models then refer to a valid WcfMexDocumentUrl address and import in BCS succeeds.