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.

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.

Gateway troubleshooting tools

• GW 2.0 SP5: Which Tools Can Be Used for Troubleshooting
• For Payload tracing:
  • Generic Channel: txn SRT_UTIL
  • OData + Generic Channel: txn SMICM (ICF trace tools)
• RESTClient (Firefox and Chrome)
• Firefox Tamper Data plug-in
• Wireshark (HTTP Protocol analyzer)
• ABAP Function Modules and services: External Debugging
• SAP system HTTP Logging