Day: February 7, 2018

In release 1708 (Q3 2017) SAP SuccessFactors delivered a GAME CHANGER to the performance potential calibration grids (AKA Talent Reviews, 9 box placements, performance potential assessments). The ability to add a description to each “box” or assessment name within the calibration session was added. Throughout my years (8) of supporting the tool from the front end as a client, to my recent switch to a consultant (2 years +) this has been a gap when utilizing the calibration module. To assist managers, documents with instructional text were loaded to a share point and a link provided or emailed to participants. All were created from scratch and not integrated with the sessions and templates.

With this feature, the description is associated with the label, furthering the clarification of what the assessment rating truly means. Understanding the description and not just the rating label furthers the accuracy of the assessment. These types of descriptions also help managers who are in organizations that share talent review data with their employees. You may have a very hard worker rated high on performance but medium on potential. The description assists with the employee and manager discussion, giving the manager even more details to share and allowing the focus of the conversation to be on development conversation.

Below are instructions for enabling and adding the content.

Enable enhancement:

* Admin Center -> Manage Calibration Settings -> Global Settings.
* Select “Enable Fiori Restyling for Calibration” and click “Save”.

Configure descriptions:

* Admin Center –> Manage Calibration Templates –> Select appropriate template or Create a new template.
* Within the template select Views and click on the tab with the 9 box (Performance/Potential) setup.
* Navigate to the grid setup and find the “note” section. Add descriptions for the labels within this section.

Descriptions within sessions:

* Once the session is activated, find the “i” (info icon) within the boxes.
* The description will then appear for review.

Happy Talent Reviews! http://bit.ly/2EOYI53 #SAP #SAPCloud #AI

Previous post in this series: Discovering SCP Workflow – The Monitor.

In this post we explore the part of the SCP Workflow API that deals with workflow instances, and look particularly at how we initiate a new workflow instance, paying particular attention to how we request, and then use, a cross site request forgery (XSRF) token.

In Discovering SCP Workflow – The Monitor, we saw that the Workflow API exposes these main entities:

Workflow Definitions
Workflow Instances
User Task Instances
Messages

We also understand that a workflow instance is a specific occurrence of a given workflow definition. So one might guess, again correctly, that as the Workflow API is informed by REST principles, we should look to the Workflow Instances entity to see how we might start a new workflow instance using the appropriate HTTP method.

Workflow instance operations

In the API documentation, the operations for Workflow Instances are shown as follows:

Considering that initiating a new workflow instance is certainly not idempotent, our eyes are drawn towards: POST /v1/workflow-instances

While our eyes are wandering over the operations summary, they also surely fall upon the path info given for some of the operations … whereupon we can surmise that workflow instances have context, error messages, and execution logs (in fact, we looked at some execution logs in Discovering SCP Workflow – The Monitor). Perhaps we’ll cover that in another installment.

Creating a new instance

Looking in more detail at the requirements for the POST operation call, we can see the following:

* the resource here is protected against cross site request forgery and an XSRF token will need to be supplied in each request

* the payload to supply is to be in JSON format, with two properties:

* definitionId: the ID of the actual workflow definition
* context: the data pertaining to the particular workflow instance to be initiated

It’s great to see that a successful response returns HTTP status code 201 CREATED, as it should, in a RESTful sense. As far as I can see, the Location header, that should normally accompany a 201 response, is missing (and the request URL is certainly not the location of the newly created resource, which is the alternative when no Location header is supplied). But let’s leave that for another time.

Regardless, the process is therefore fairly straightforward. Let’s have a look at some sample code from Archana Shukla ‘s post “Part 2: Start Workflow from your HTML5 application” to embed the process into our brains.

Fetching the XSRF token

First, we have the _fetchToken function defined thus: _fetchToken: function() { var token; $.ajax({ url: “/bpmworkflowruntime/rest/v1/xsrf-token”, method: “GET”, async: false, headers: { “X-CSRF-Token”: “Fetch” }, success: function(result, xhr, data) { token = data.getResponseHeader(“X-CSRF-Token”); } }); return token; }

This _fetchToken method is called before the main POST method (that’s the one that actually initiates the new instance). Let’s look closely.

There’s a GET request made to the following URL: /bpmworkflowruntime/rest/v1/xsrf-token

This URL is of course abstracted by the destination target entry in the app’s neo-app.json descriptor file, which has an entryPath defined as “/workflow-service”: { “path”: “bpmworkflowruntime”, “target”: { “type”: “destination”, “name”: “bpmworkflowruntime”, “entryPath”: “/workflow-service” }, “description”: “Workflow Service Runtime” }

Digression: Resource URLs and how to think about them

It’s worth stopping briefly to consider what this means and in what way we look at this Workflow API (and APIs for other services), particularly around how we think about different parts of the path info.

By the way, the “path info” is that part of the url that starts after the hostname and (optional) port, running up to any query parameters. So for example, in the URL http://host.example.com:8080/something/something-else/this?n=42

the path info part is: /something/something-else/this

So, back to the digression.

When you enable the Workflow service in the SCP cockpit, a new destination “bpmworkflowruntime” appears, with the URL pattern that looks like this for production accounts: https://bpmworkflowruntimewfs-.hana.ondemand.com

and this for trial accounts: https://bpmworkflowruntimewfs-trial.hanatrial.ondemand.com

So, with this in mind, and looking at the pattern defined for the Workflow API production URL, as described in the Overview section of the Workflow API documentation on the API Hub: https://bpmworkflowruntime{provideracctname}-{consumeracctname} .hana.ondemand.com /workflow-service/rest

(split for legibility) we can see that “wfs” is the provider account name, and that /workflowservice/rest

is the “root” part of the path info for the Workflow API resources. In other words, this “root” part is common to all resource URLs in the Workflow API.

Taking my trial account for example, it resolves to this: https://bpmworkflowruntimewfs-p481810trial .hanatrial.ondemand.com /workflow-service/rest

A complete URL for a given API resource, such as for the workflow instances, would look like this: https://bpmworkflowruntimewfs-p481810trial .hanatrial.ondemand.com /workflow-service/rest/v1/workflow-instances

You can see that after the “root” part of the path info, we have the resource-specific part: /v1/workflow-instances

This might seem like an unnecessary diversion, but I think it’s important to understand how resource identifiers (URLs) are structured, so you can think about them in an appropriate way, and have that thinking permeate your code and configuration.

So I think here it might be nicer to have a destination target entry like this: { “path”: “workflowservice”, Host: bpmworkflowruntimewfs-p481810trial.hanatrial.ondemand.com > User-Agent: curl/7.52.1 > Accept: */* > X-CSRF-Token: Fetch > Host: bpmworkflowruntimewfs-p481810trial.hanatrial.ondemand.com > User-Agent: curl/7.52.1 > Accept: */* > Content-Type: application/json > X-CSRF-Token: 10D04A3B50DDE972188AA980DFDC56D9 > Content-Length: 69 > } [69 bytes data] GET /workflow-service/rest/v1/xsrf-token HTTP/1.1 > Host: bpmworkflowruntimewfs-p481810trial.hanatrial.ondemand.com > User-Agent: curl/7.52.1 > Accept: */* > X-CSRF-Token: Fetch > Host: bpmworkflowruntimewfs-p481810trial.hanatrial.ondemand.com > User-Agent: curl/7.52.1 > Accept: */* > Cookie: JSESSIONID=2C505C957AD0B1E76BD0535F0AF66C10DD824F88F2FF5F3463DD56AF5020E8D0; BIGipServer~jpaas_folder~bpmworkflowruntimewfs.hanatrial.ondemand.com=!kdw/bjE6WrgieXWwDhtcRsHHmTA76BykeAKzJSQCxdxLV7mHZYmet6Q6LvtTA6c9gdNjkRxfo0Gi4So=; JTENANTSESSIONID_p481810trial=iIN12zFf3bAmLNOQA3tuM4YVkPI2WgN060d0hgv%2B6W4%3D > Content-Type: application/json > Content-Length: 69 >

Last week I told my teammate Abdel DADOUCHE about using SAP HANA geospatial capabilities to calculate the center of continents, and that based on those calculations the centroid of Europe is in Belarus and the middle point is on some isle in the Baltic Sea. “Accordingly to what borders?” he replied. That’s a good question, as even today there are discussions going on where and if the border between Asia and Europe should be placed. That “border remains a historical and cultural construct, defined by convention“, but on the map I used so far in SAP HANA it is real and defined. Let us use that map in the current exercise as well.

So far for my previous calculations I took the European continent as one geometry, which consists of the mainland and numerous islands. How many single polygons constitute European continent? In the map I loaded (and you hopefully too) there are 296 polygons of Europe accordingly to geospatial function ST_NumGeometries(). SELECT “SHAPE”.ST_NumGeometries() FROM “TESTGEO”.“continent” WHERE CONTINENT=‘Europe’; –The result is 296

Only one out of these 296 geometries is the continent’s mainland; all others are islands. And I want to find the center point of the mainland part of Europe. Obviously it will be the polygon with the biggest area, so I need to iterate through all these 296 parts to find the biggest one. This is where SQLScript with its support for spatial in SAP HANA comes handy.

Here is my code (and please feel free to comment how you would improve it!). The procedure returns three geometries: mainland, centroid and middle point – all formatted as a GeoJSON string, and not WKT this time. SET SCHEMA TESTGEO; DROP PROCEDURE “TESTGEO”.“CONTINENT_MAINLAND_CENTER_GEOJSON”; CREATE PROCEDURE “TESTGEO”.“CONTINENT_MAINLAND_CENTER_GEOJSON” (IN continent_name NVARCHAR (20), OUT nr_shapes INT, OUT mainland CLOB, OUT point_centroid CLOB, OUT point_middle CLOB) LANGUAGE SQLSCRIPT READS SQL DATA AS whole_continet ST_GEOMETRY; BEGIN DECLARE single_shape, theshape, temp_shape ST_GEOMETRY; DECLARE shape_area, shapei_area DECIMAL = 0; DECLARE i INTEGER; select “SHAPE” into whole_continet FROM “TESTGEO”.“continent” WHERE CONTINENT=:continent_name; nr_shapes := whole_continet.ST_NumGeometries(); FOR i IN 1..nr_shapes DO single_shape := :whole_continet.ST_GeometryN(i); shapei_area := single_shape.ST_Area(); IF shape_area ‘Europe’, NR_SHAPES => ?, MAINLAND => ?, POINT_CENTROID => ?, POINT_MIDDLE => ? );

Using GeoJSON in the output allows us to easily place results on the map for visualization using services like GeoJSONLint.

Interesting… So for the mainland both – the centroid and the middle point – are in Belarus!

Regards,

-Vitaliy, aka @Sygyzmundovych
—

This and other exercises were part of the very first SAP CodeJam on the topic of professing geospatial data with SAP HANA in Walldorf, Germany. I’d like to thank as well Markus Fath and Christian Schuetz from SAP HQ office joining to share some more real life use cases and demos of SAP HANA geospatial processing capabilities!

Interested in the topic and would like to host such a CodeJam in your home town? Just follow these steps to request and to host one.

[Picture by Fabian Lehmann] http://bit.ly/2Bgajdt #SAP #SAPCloud #AI

Each year, employers that provide prescription drug coverage to Medicare-eligible workers, dependents or retirees must disclose to the Centers for Medicare and Medicaid Services whether their drug coverage is as good, or not as good, as Medicare Part D. For sponsors of calendar-year plans, the deadline is March 1. https://goo.gl/R5rcnL #GlobalHR #HRTech