SAP FSM Lifehack: Using a custom object to manage Credentials

FSM has a lot of great features, but also a few pain points, especially in the admin section, which go unnoticed.

Therefore, it is up to each consulting team to use their imagination in circumventing them. One of them is the storage and maintenance of technical verification data, the so-called credentials. If the company wants to make full use of the potential of FSM, it will not avoid setting business rules, which are the backbone of system automation. For simpler extensions, the implementation consultant will suffice with actions such as Create / Update / Delete Object, Send Email, Push notifications, etc. But if there are already more complex requirements when e.g. business rule with its updated object must invoke another business rule, it is necessary to update several records of the object and send data to another system, the consultant must reach for actions such as Webhook and FSM Webhook. The essence of this action is to call the API, which must already contain certain security elements. The purpose of this blog is to inspire you in regards to their easier management.

As an example, I will mention the use of Client ID and Client Secret, which must be entered in the FSM Webhook action. Generation of both is possible in the admin section of the Clients section (at the Account level). The system generates Client ID and Client Secret, and the first major inconvenience arises here. It is possible to access the Client Id at a later point in time, but if you do not save the Client Secret when it is generated, you will not be able to access it anymore. And this becomes all the more annoying if there are several consultants working on setting up the system, who need to know this information.

Another big disadvantage is that when you transfer the created business rule from the development system to the test or production system, it is necessary to re-enter the Client Secret into the FSM Webhook event. Experience has taught us that many manual steps are increasing the chances of an unforeseen error, so my colleagues and I came up with a workaround.

Creating a custom object

We have created a new custom object name Credentials for storing access data with fields: Name, Description, User, Password, Key.

Note: The Key field is not required for Client ID and Client Secret. We use this field for authorization tokens to external systems such as ERP, Google Forms, etc.

We will then create the obtained Client ID and Client Secret as a record of a new object with a unique name.

The credentials stored in this way make it easier for administrators to collaborate as well as manage security, as it is possible to regularly generate new ID + Secret and easily restore system security by changing this object’s record without having to laboriously search all business rules that include FSM Webhook and update the hard-coded credentials in them one by one.

Select data in Variables of the business rules

Instead of hard coding the value of both data into a business rule, we create a SELECT over our new object in Variables. It is possible to create a variable of type Value separately for Client ID and Client Secret, but we decided to go in the form of 1 variable of type Array as we use business rules, where we catch up to 4 different records of the Credentials object.

Sample select for Client ID and Client Secret:

SELECT a.udf.z_f_udo_credentials_user AS clientId, a.udf.z_f_udo_credentials_password AS clientSecret FROM UdoValue a WHERE a.udf.z_f_udo_credentials_name = ‘Client ID and Client Secret for API calls’

In cases where you need to retrieve multiple credentials, you can apply a JOIN to the same UdoValue object, matching the objects according to the same UdoValue.meta. The rule is – one record for each new JOIN:

SELECT a.udf.z_f_udo_credentials_user AS ClientID, a.udf.z_f_udo_credentials_password AS ClientSecret, b.udf.z_f_udo_credentials_key AS GoogleForms FROM UdoValue a JOIN UdoValue b ON a.meta = b.meta

WHERE a.udf.z_f_udo_credentials_name = ‘Client ID and Client Secret for API calls’ AND b.udf.z_f_udo_credentials_name = ‘GOOGLE_FORMS‘

Adding data to the action

The last step is to create an action of the FSM Webhook type, where we use the retrieved values from the select in respective fields of this action – Client Id and Client Secret. In our case these are: $ {creds [0].clientId} and $ {creds [0].clientSecret}

Tip: The Client Secret field does not show the written value, so I recommend writing down the given formula and then just copying it to the given field.

Filip Žarnovický, CX Consultant