Day: February 13, 2018

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/2sucXJR #SAP #SAPCloud #AI

It is our goal to continuously improve simulating and troubleshooting message processing in Cloud Integration. With the release of version 2.36 a new log level is introduced which collects message content in addition to the message processing log. This blog describes how this feature can be utilized and the relation to existing log levels which are described in detail in Setting the log level for message processing.

While developing or testing an integration scenario, the message processing log provides information about the status and the steps executed on a configurable level of detail. In scenarios where the message itself gets transformed during processing it can be extremely useful to monitor the message content at different stages as well.

The new log level Trace, like any other log level, can be set for a specific integration flow in the “Log Configuration” section of the “Manage Integration Content” view of the Web-based Monitor (see Product Documentation for details).

Figure 1: Setting the Log Level for an Integration Flow

In the “Monitor Message Processing” view of the Web-based Monitor the log level used when writing the log is visible in both the overview list and the details view which allows selecting the desired log from multiple ones for the same integration flow.

Figure 2: Selecting a Message Processing Log

However, there are some notable differences between Trace and the other log levels.

* Messages may contain sensitive data. Thus, access to message content is restricted to users having Business Expert role.
* Messages may contain a large amount of data. To prevent exhaustion of resources tracing expires after some time, typically 10 minutes and the message content collected during this period is retained for typically 1 hour only.

Due to these reasons the message content is not written to the message processing log but stored separately, allowing a different access level and lifecycle.

When tracing is enabled the message processing log will be written at the highest possible detail level (same as for log level Debug) and the message content gets collected and stored. After expiry of trace during an execution of an integration flow the collection of message content is stopped but the message processing log will still be written on the most detailed level. For subsequent executions, the log level falls back to the one which was set for the integration flow prior to Trace.

The time of Trace expiration as well as the previous log level is displayed in “Manage Integration Content” details.

Figure 3: Getting Trace expiry information

It is worth noting that the log level to be used is determined once at each start of processing a message. This can be useful in retry scenarios where the message processing log consists of multiple parts, one for each try. By changing the log level while such an integration flow is in Retry status, log parts can have a different level of detail and even messages can be traced regardless of the log level which was active when the integration flow was started.

For the time being the message content persisted while tracing can be viewed with the Integration Operations Feature in Eclipse only (see View Trace). Future increments will provide a similar feature in Web-based Monitor as well.

SAP recommends to use tracing in non-productive environments only.

I hope you find this new feature useful. Please feel free to comment on this blog in case you have questions or feedback. http://bit.ly/2BurmJa #SAP #SAPCloud #AI