SharePoint integration endpoints for a SAPUI5 based PeopleFinder

SAPUI5 is a suitable framework to build responsive-design UIs that renders to the available screen estate of diverse device types: smartphone, tablet, and desktop. It is therefore a fit to deliver an alternative UI to SharePoint's PeopleFinder functionality, in case the out-of-the-box SharePoint UI (that is, with potentially the rendering still made company specific via customized Search Display Templates) for whatever reason does not qualify as sufficient fit. The basic requirement of a SAPUI5 mobile application is that it can consume data and functionality via OData REST services. The SharePoint platform supports such an architecture via the standard SharePoint REST services:

The integration surface for a peoplefinder functionality comprises 3 main elements:

1. To interactive present people suggestions to user while typing in characters of the people name ==> Get names list of matched users on search input
2. Get detailed list of matched users on search input
3. Get details for selected user

1. Get names list of matched users on search input

Best:

SharePoint end-point

https://<SharePoint root-url>/_api/search/query?querytext='preferredname:Jones*'''&selectproperties='PreferredName'&sourceid='B09A7990-05EA-4AF9-81EF-EDFAB16C4E31'&rowlimit=10

Alternative is to search in User Information List:

SharePoint end-point

https://<SharePoint root-url>/_vti_bin/listdata.svc/UserInformationList?$filter=((ContentType eq 'Person') and (substringof('Jones',LastName)))&$orderby=Name

but this has some disadvantages:

• Incomplete qua users: user is only added to UserInformationList on first visit to SharePoint site; users not visited yet, are not included
• Overcomplete: UserInformationList is never cleaned up, former colleagues remain in the list
• Incomplete qua search: UserInformation does not contain a full name field

2. Get detailed list of matched users on search input

Search in full content / all crawled people data fields:

SharePoint end-point

https:// <SharePoint root-url>/_api/search/query?querytext='Mobile*'&selectproperties='FirstName,LastName'&sourceid='B09A7990-05EA-4AF9-81EF-EDFAB16C4E31'&rowlimit=10

Search in identified property-field(s) only:

SharePoint end-point

https:// <SharePoint root-url>/_api/search/query?querytext='department:Mobile*'&selectproperties='FirstName,LastName'&sourceid='B09A7990-05EA-4AF9-81EF-EDFAB16C4E31'&rowlimit=10

3. Get details for selected user

Get all public properties:

SharePoint end-point

https:// <SharePoint root-url>/_api/SP.UserProfiles.PeopleManager/GetPropertiesFor(accountName=@v)?@v='<uname of user>'

Get one single identified user profile property only:

SharePoint end-point

https://<SharePoint root-url>/_api/SP.UserProfiles.PeopleManager/GetUserProfilePropertyFor(accountName=@v,propertyName='AboutMe')?@v='<uname of user>'

The SAP Mobile Integration playing field

SAP NetWeaver Gateway, SAP Mobile Platform, SAP API Management, Integration Gateway: the SAP Mobile Integration playing field includes multiple players. What are their roles, and can they play well together?

SAP Mobile Integration technologies and products

The role of SAP NetWeaver Gateway is exposing SAP ABAP-based Business Suites for consumption by alternative UI-channels, SAP and non-SAP. Including mobile apps, a.o. the SAP Fiori Apps.

SAP delivers also SAP Mobile Platform as a standard product. SMP 3.0 includes an internal component Integration Gateway. This is something different than NetWeaver Gateway, although it’s role is comparable: expose data and functionality for external consumption. Starting SMP 3.0 service pack 4, SAP positions SMP also as “Fiori-compatible”. Elements of this are SAP Fiori Client and Kapsel SDK within the SMP portfolio.

Early October, SAP in addition launched the new product SAP API Management. With this product, organization can manage and govern their service provisioning and usage by consuming organisations and Apps. Also this product thus has its rol in the mobile integration landscape.

How do these products play along?

SAP itself acknowledges that the pure existence of these 3 products, which seem to functionally overlap, likely will result in market confusion. To mitigate that effect, Joav Bally wrote an excellent article to clarify on higher level the difference in role positioning. Instead of repeating him, I simple refer to his post: Uniform Provisioning and Consumption of SAP (and non-SAP) Data. Another good information source is the post ‘There is a Gateway for that …’ by Mustafa Saglam.

Inspired by the insights I gained via these 2 blogs, I sketched a conceptual architecture diagram in which the 3 SAP integration products/technologies are positioned in the architecture layers.

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.

Experiences from building a first SAP Gateway + SUP Mobile App

Just for Christmas holidays we successfully implemented at customer premisse their first custom-developed App utilizing the SAP Mobile Platform. The App is a so-called productivy application, and enables managers to execute routine approval tasks at arbitrair moments and locations [inside and outside office buildings + network] that suite the manager best. The approval tasks originate from SAP workflows, e.g. HCM expense handling business process.

The road to this achievement was rather bumpy, not in the least because this was the first project in which multiple recent SAP technology developments where utilized and validated. SAP NetWeaver Gateway OData services, Sybase Unwired Platform 2.1.x, Sybase Afaria.

Conclusions / Important lessons learned

1. Standard Gateway WFService can be used to expose SAP workflow tasks with user involvement, to non-SAP front-end
2. 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
3. Mobility platforms and technologies are evolving fast; in general and in particular this also holds for SAP Mobile Platform
1. 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
2. The current state of the platforms and technologies is sufficient, but does require us to apply some workarounds and accept some sub-optimal execution.
4. Pull architecure is recommended for Gateway OData based App
5. User-centric Design is key to deliver an App that the end-users are actually willing to use
6. 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.
7. 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?

Expose SAP data to outside consumers can be achieved either by:

• Pull: Consumer requests the data from SAP
• Push: SAP Business Suite activily propagates the SAP data to any interested consumer.

Both architectures have their value. But in general the recommendation is to apply the Pull architecture, and only consider the Push architecture when Pull cannot deliver. Most important reason is that Push architecture is a lot more complex for consumer to handle correctly. The consumer must be able to ad-hoc handle the received notifications from the publishing SAP business suite, optional per received notification still invoke the backend to retrieve additional data, and maintain plus synchronize a local repository on the device. SUP Mobile Business Objects (MBO) is designed to support this and includes data-synchronization support. But SUP OData does not [yet] include support for this, and is by default better suited for pull-scenarios.

Note: In a next blogpost I will go into more detail on the Pull versus Push architectural decision.

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.