Monday Knowledge Snippet (MKS) – 42 Automated GIS service availability testing
GIS services can play an important role for SAP Transportation management. Today’s MKS gives an idea how to secure the availability of those services provided by SAP TM external servers. Not so much standard, more an insight how I do it internally.
Background: Basically GIS service used in SAP TM increase the data quality of the master data and hereby the business processes like transportation planning. Out of the master data location address a geo-coding service determines geo-coordinates. Those coordinates are used to display the location on the map and serve as basis for the distance and duration calculation between 2 locations. Such a distance and duration determination can be execute using a GIS service respecting real streets and restrictions. In case no external services are connected, SAP TM uses standard values for coordinates on region level and a straight line distance determination. Of course not want you want when you schedule a truck between your warehouse and a customer.
In case the business requires high data quality, it is crucial to ensure the availability of the services. Of course those services can be delivered by network internal resources (in-house GIS) or external servers or cloud. When the external service is down, SAP TM as already mentioned uses fall-back solutions with lower quality. But still you get a result and it is not at first sight transparent that it is not based on the GIS services. Especially when for example running transportation planning for many orders (maybe scheduled in background), the results can mess up the complete day.
Solution: For the GIS infrastructure used here at SAP internally, I have setup an automated availability checker that first checks all required GIS settings and fires test requests at the connected servers. In case no valid result is returned I am informed by e-mail. In addition there is a history log where I can see the availability over time.
Here is how I have done that:
1. Define a test set both for geo-coding and distance/duration determination fitting your business
– for example define addresses where you expect geo-coordinates
– use the level of test granularity required (by country, region, city, …)
2. Create a report firing the test requests and evaluating the results
– pass the test set to the required function executing the GIS service call: this can directly be your custom implementation for your GIS provider or the standard SAP function (this then includes the check if your GIS settings are correct)
– GeoCoding: /SCMB/CL_DIST_DUR_DET=>DETERMINE_GEO_COORDINATES
– Distances: /SCMB/CL_DIST_DUR_DET=>DETERMINE_DISTANCE_DURATION
My report checks the GIS services every 10 minutes, but this can be setup as required.
3. [Log the results in a db table if required]
My table is pretty simple: CHECK_TIME | STATUS_GIS | MAIL_SEND
With the last solumn I avoid to get hundreds of mails when the service is down over night or during vacation. The report checks if the mail was send already and does not send another one.
4. Send an e-mail when services are down
That’s it. Helped me a lot with our internal systems to get an overview and quickly recognize when something is down. Don’t want to disturb important demos.
In case there is interest I can spend another MKS on sending mails…
Here is the LinkedIn discussion: Monday Knowledge Snippet (MKS) - 42 Automated GIS service availability testing | LinkedIn
Interesting topic Marcus.
How often do you face issues with GIS services? Would be better/viable to trigger when the user execute the planning cockpit and show an alert in the map?
Internally quite often as our in-house GIS servers are updated pretty often with internal stuff and get stuck in re-boot. In real live calling external services like NOKIAs HERE platform, this should not occur do to service level agreements including high availability.
Your idea is cool.
Hello Eduardo and Marcus,
Maybe the performance issue for this scenario(detailed distance calculantion based on GIS) is not only due to GIS calls but the optimizer complexity too.
Kind Regards, Marcelo Lauria