This blog is in continuation to my earlier blog (http://scn.sap.com/community/duet-enterprise/blog/2013/04/01/duet-enterprise-infrastructure-setup-difficult-really) where I listed some important points to consider while setting up Duet Enterprise for SAP and SharePoint Integration.
In this blog, I would try a feature wise call stack dissection for Duet Enterprise 1.0 FP1. It is strictly applicable for 1.0 FP1 scenarios only where integration between SAP and SharePoint 2010 is required. Currently, this information is scattered between Duet Enterprise and Gateway’s configuration guides and it becomes difficult to understand the big picture.
This might results into higher configuration costs. Hence, a level of clarity in big picture is a MUST before you start your Duet Enterprise Configuration.
So, let’s try to understand (feature wise) connectivity behind every call processed in your SAP Landscape. The software components to be used and version details could be found here (http://scn.sap.com/thread/1984980)
Starter Services and CRUD + Q Operations (This is Online or Synchronous Request/Response Cycle)
SharePoint to Gateway/Duet Enterprise Server: HTTPS Calls with SAML Tokens for SSO (Utilizing User Mappings done in Gateway or LDAP)
Gateway/Duet Enterprise Server to SAP Backend:
- a) Trusted RFC Calls (Type 3 RFCs – ABAP Connections)with current user for SSO for custom RFCs(CRUD) and some of Starter Services.
- b) HTTP Calls (Type H RFCs – HTTP Connection to ABAP Systems) with Logon Tickets for SSOfor some Starter Services. Both backend and Gateway must be enabled to create/accept Logon Tickets.
SAP Backend to Gateway/Duet Enterprise Server:
a) Online Trusted RFC Response (Type 3 RFCs – ABAP Connections) for custom RFC Calls (CRUD) and some of Starter Services.
b) Online HTTP Response (via already opened HTTP Connection) with Logon Tickets for SSO for some of the Starter Services.
Note 1: If you want to use SSL for these HTTP Calls here, then exchange certificates betweenBackend and Gateway Server but make sure to secure your RFCs with SNC too!
(Courtesy – Holger Bruchelt from Duet Enterprise Solution Management)
Gateway/Duet Enterprise Server to SharePoint: HTTPS response utilizing User Mappings in Gateway/LDAP
Reporting Feature: Request and Publishing
(This is generally Offline or Asynchronous Request/Response Cycle)
Report Request from SharePoint to Gateway/Duet Enterprise Server: HTTPS Calls with SAML Tokens for SSO (Utilizing User Mappings done in Gateway or LDAP)
Gateway/Duet Enterprise Server to SAP Backend: Trusted RFC Calls (Type 3 – ABAP Connections) with current user for SSO.
The report request ends here. As the next step, response is built in the format specified in the Reporting Configuration (Excel, PDF etc.).
Advantage for making this setup asynchronous is that SharePoint doesn’t have to wait in case of bulky SAP Reports and it doesn’t choke your network bandwidth (No Waiting/Open HTTP Connections while processing inside Gateway/Backend). Though, it poses some challenges from monitoring/failure analysis point of view but we have a few good tools from Gateway here:
- a) /iwfnd/apps_log (This log clearly shows every call in both backend and Gateway with directions)
- b) srtutil or /iwfnd/error_log
- c) A special guide from SAP on tracing problems in this feature (Check Duet Enterprise Self-Paced Learning Page)
Having said that, this is how the response cycle looks like in this case:
Report Publishing from Backend to Gateway: A new HTTP Call (Type H – HTTP Connection to ABAP Systems) with Logon Tickets for SSO. Please refer Note 1 in this case too.
Report Publishing from Gateway/Duet Server to SharePoint: A new HTTP Call to SharePoint’s OBA File Receiver Web Service via a specific Report Publisher User in the Gateway System. Web Service details and publisher user’s credentialscould be setup via setting up endpoints in consumer proxy during Reporting configurations on SAP side.
Workflow Feature: Workitem Publishing from SAP to SharePoint
(In this case process is initiated by SAP Backend Mostly, and then there could be separate calls from SharePoint to publish decisions on workitems)
Workitem Publishing from Backend to Gateway/Duet Enterprise Server:
HTTP Calls (Type H – HTTP Connection to ABAP Systems) with Logon Tickets for SSO. Note 1 applies in this case too.
Workitem Publishing from Gateway/Duet Enterprise Server to SharePoint:
HTTP Calls to SharePoint’s OBA File Receiver Web Service via a specific Workflow Publisher User in the Gateway System. Web Service details and publisher user’s credentials could be setup via setting up endpoints in consumer proxy during Reporting configurations on SAP side.
Propagation of Decision (with Information) on Workflow Tasks from SharePoint to Gateway /Duet Enterprise: These published tasks are when acted upon by decision makers who are using SharePoint UI, a new HTTP connection (and uses SAML Tokens for SSO) is created to propagate this tasks level information to Gateway.
Propagation of Decision (with Information) on Workflow Tasks from Gateway/ Duet Enterprise to SAP backend: Trusted RFC Calls (Type 3 – ABAP Connections) with current user for SSO.
Role Synchronization/Propagation from SAP to SharePoint
SAP Backend to Gateway/Duet Enterprise: In Gateway System, Roles, which are configured for use in SharePoint as a consumer,are brought in from backend via a System Alias (Type 3 RFC Destination).
Gateway/ Duet Enterprise to SharePoint: This call is performed by a Timer Job on SharePoint, which reads Gateway’s User-Role Table named /IWFND/D_RS_DATA via a HTTP Call (Web Service) via a fixed mapped backend Service User in Gateway. Thus, mapping the background service user is also important for setting up Role Synchronization.
There is one more connection which exists in this landscape but not included in this call stack for the sake of keeping it simpler – Gateway to ESR. Web Service definitions (data types etc.) come from the ESR system, which is hosted by either your NetWeaver PI or CE System. This is again an HTTP Connection. ESR, in turn, could be connected to SLD (Software component versions could be imported from SLD as well).
I hope this would be valuable information while starting your SAP and SharePoint 2010 Integration. In next and last blog of this series I would try to dissect Duet Enterprise 2.0 call stack.
Lastly, I would say, if you feel I have missed or misunderstood anything, you are more than welcome to use comments section below for more interesting discussions.
To be continued…