SAP FSM Lifehack: Brug af et brugerdefineret objekt til at administrere legitimationsoplysninger

FSM har mange gode funktioner, men også et par smertepunkter, især i administratordelen, som ikke bliver bemærket.

Derfor er det op til hvert enkelt konsulentteam at bruge sin fantasi til at omgå dem. En af dem er opbevaring og vedligeholdelse af tekniske verifikationsdata, de såkaldte legitimationsoplysninger. Hvis virksomheden ønsker at udnytte FSM’s potentiale fuldt ud, kan den ikke undgå at opstille forretningsregler, som er rygraden i systemautomatiseringen. For enklere udvidelser vil implementeringskonsulenten være tilstrækkelig med handlinger som Opret/opdatér/slet objekt, Send e-mail, Push-meddelelser osv. Men hvis der allerede er mere komplekse krav, når f.eks. en forretningsregel med sit opdaterede objekt skal påberåbe sig en anden forretningsregel, det er nødvendigt at opdatere flere poster i objektet og sende data til et andet system, skal konsulenten vælge handlinger som Webhook og FSM Webhook. Essensen af denne handling er at kalde API’et, som allerede skal indeholde visse sikkerhedselementer. Formålet med denne blog er at inspirere dig til at gøre det nemmere at administrere dem.

Som et eksempel nævner jeg brugen af Client ID og Client Secret, som skal indtastes i FSM Webhook-aktionen. Det er muligt at generere begge dele i administrationsafsnittet i afsnittet Kunder (på kontoniveau). Systemet genererer klient-id og klienthemmelighed, og den første store ulempe opstår her. Det er muligt at få adgang til klient-id’et på et senere tidspunkt, men hvis du ikke gemmer klienthemmeligheden, når den genereres, vil du ikke længere kunne få adgang til den. Og det bliver endnu mere irriterende, hvis der er flere konsulenter, der arbejder på at oprette systemet, og som har brug for at kende disse oplysninger.

En anden stor ulempe er, at når du overfører den oprettede forretningsregel fra udviklingssystemet til test- eller produktionssystemet, er det nødvendigt at indtaste Client Secret på ny i FSM Webhook-hændelsen. Erfaringen har lært os, at mange manuelle trin øger risikoen for en uforudset fejl, så mine kolleger og jeg fandt en løsning på problemet.

Oprettelse af et brugerdefineret objekt

Vi har oprettet et nyt brugerdefineret objekt med navnet Credentials til lagring af adgangsdata med felter: Navn, Beskrivelse, Bruger, Adgangskode, Nøgle.

Bemærk: Nøglefeltet er ikke påkrævet for klient-id og klienthemmelighed. Vi bruger dette felt til godkendelsestokens til eksterne systemer som ERP, Google Forms osv.

Vi opretter derefter det opnåede klient-id og klienthemmeligheden som en post i et nyt objekt med et unikt navn.

De legitimationsoplysninger, der er gemt på denne måde, gør det lettere for administratorer at samarbejde og administrere sikkerheden, da det er muligt regelmæssigt at generere nyt ID + Secret og nemt at genoprette systemsikkerheden ved at ændre dette objekts registrering uden at skulle gennemsøge alle forretningsregler, der omfatter FSM Webhook, og opdatere de hårdt kodede legitimationsoplysninger i dem en efter en.

Vælg data i Variabler i forretningsreglerne

I stedet for at fastkode værdien af begge data i en forretningsregel opretter vi et SELECT-objekt over vores nye objekt i Variables. Det er muligt at oprette en variabel af typen Value separat for Client ID og Client Secret, men vi besluttede at vælge 1 variabel af typen Array, da vi bruger forretningsregler, hvor vi fanger op til 4 forskellige poster i Credentials-objektet.

Vælg et eksempel for klient-id og klienthemmelighed:

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 = “Klient-id og klienthemmelighed for API-opkald

I tilfælde, hvor du skal hente flere legitimationsoplysninger, kan du anvende en JOIN på det samme UdoValue-objekt og matche objekterne i henhold til den samme UdoValue.meta. Reglen er – en post for hver ny JOIN:

VÆLG 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

HVOR a.udf.z_f_udo_credentials_name = “Klient-id og klienthemmelighed for API-opkald” AND b.udf.z_f_udo_credentials_name = “GOOGLE_FORMS

Tilføjelse af data til aktionen

Det sidste trin er at oprette en handling af typen FSM Webhook, hvor vi bruger de hentede værdier fra select i de respektive felter i denne handling – Client Id og Client Secret. I vores tilfælde er disse: $ {creds [0].clientId} og $ {creds [0].clientSecret}

Tip: Feltet Client Secret viser ikke den skrevne værdi, så jeg anbefaler at skrive den givne formel ned og derefter bare kopiere den til det givne felt.

Filip Žarnovický, CX-konsulent