Kibana Visualizations: Working with Region Maps

By now, we all must have seen the demonstrations of Kibana Data Visualizer that was made available in PeopleTools 8.58. If not, it is very easy to spin up a PUM image (HCM or FSCM) and get a hands-on experience with this functionality.

While evaluating the delivered Kibana Visualizations, I noticed a few map visualizations.

For example, HCM > Workforce Administrator (Homepage) > Workforce Insight (Dashboard) > Workforce Equity (Tile) > Employee Distribution by Country (Visualization)

How does this work?

As we can see in the footer, the map is rendered to us using the Elastic Maps Service (EMS) which in turn produces basemap tiles leveraging OpenStreetMap data.

We can find more information here:
https://www.elastic.co/elastic-maps-service
https://maps.elastic.co

Further, the out-of-box Kibana functionality would directly request the maps from the browser. The EMS requests are made to the following domains:

• tiles.maps.elastic.co
  
• vectors.maps.elastic.co
  

If we run into firewall restrictions and unable to allow access to *.maps.elastic.co, we have the option of hosting the EMS locally.

We can find more information here:
https://www.elastic.co/guide/en/kibana/current/maps-connect-to-ems.html

Gotcha

When I dug in a little further to review how the application data (PS Query/Connected Query > Elasticsearch Index > Kibana Index Pattern) is hooked (or joined) to the EMS, I found a strange Kibana bug (?).

Here is the 'Data' tab of the Visualization configuration in Kibana. We can see that the COUNTRY field in PeopleSoft is being used as the aggregation field.

Now, if we go to the 'Options' tab, we will see that the Join Field for the EMS Vector map (World Countries) is set to 'ISO 3166-1 alpha-2 code'.

Wait a minute. The COUNTRY field in PeopleSoft is the 3 character ISO code but somehow it is joined with the 2 character ISO code. How is this possible? Am I right?

We can even preview on EMS to see the codes. If you don't believe me.

After scratching my head for a long time, I found that this is a bug with respect to the display of the Join Field in the Kibana configuration. It possibly may be defaulting to the first value that is in the drop-down. However, once I reviewed the actual JSON configuration (Saved Object) of the visualization, I found that it is in fact using the 'ISO 3166-1 alpha-3 code'. So, it proves that I was not losing my mind (at least as yet!). 😅

Exploring

Next, I wanted to build a map on my own. I used the same data 'Employee Distribution' and represented it per Country and State instead of just the Country.

I created an expression in my PS Query (used in Connected Query source for Search Definition) that concatenates COUNTRY_2CHAR and STATE fields into a single query field.

Next, I created a visualization in Kibana using this field as the Join Field for an 'Administrative region' vector map - 'Region ISO code'.

I look forward to your questions, comments and feedback (please use the comments section below).

SignOn PeopleCode: Base64 Decode + Inflate

This is a follow-up to my previous post where we saw how we can Deflate + Base64 Encode a SAML Request. 

Refer: https://pe0ples0ft.blogspot.com/2021/03/sso-deflate-base64-encode-saml.html

Here is an example of the reverse - Base64 Decode + Inflate:

SignOn PeopleCode: Deflate + Base64 Encode (SAML Request)

Often, I hear questions about PeopleSoft's support for SAML, OAuth or other types of SSO. I have also seen some bolt-on solutions that are available for purchase. My thoughts on this age old question is as follows:

Signon PeopleCode + SetAuthenticationResult Function + PeopleCode Java Functions

Signon PeopleCode is incredibly flexible and allows us to build any custom SSO integration that might be unique to our requirements. Couple this with the built in SetAuthenticationResult function (to manage redirects and authentication) and PeopleCode Java functions, we have everything that we need to develop an integration with any SSO solution.

Working on PeopleSoft SSO implementations is interesting. No matter what standard or tailored solution we choose, there is always something unique with each environment. I plan to write more follow-up posts on this topic! Stay tuned.

This brings my focus to the purpose of this particular post. A SignOn PeopleCode requirement that was brought to my attention by Diego De Boni - a colleague (and a new friend) in the PeopleSoft community!

The requirement is to Deflate and Base64 encode a string (in this case a SAML Request) in SignOn PeopleCode. This is where PeopleCode Java functions come in handy!

Useful Resources:
What is SAML and how does it work?
SAML Developer Tools - Deflate + Base64 Encode SAML Message

Here is an example of a simple string "ABCDE" that is deflated and Base64 encoded. This string could be replaced with a SAML Request for real use cases.

Before I could come up with a solution, Diego beat me to it and found a way to achieve the Deflate + Base64 encoding using Java in Signon PeopleCode. I asked his permission to share the following sample code as it will help many others in the community. More importantly, it shows the power of this formula:

Signon PeopleCode + SetAuthenticationResult Function + PeopleCode Java Functions

Signon PeopleCode Snippet

I look forward to your comments and feedback (please use the comments section).