In the documentation for automation best practices are some examples where the workspace is hardcoded - this means when cloning from prod to sandbox (or vice versa) those references have to be updated.
Is there a way to do this via 'some global variable' or else?
Would you be so kind to share an idea…
Best regards,
Gotthard
Best answer by Thomas Schreiner
Hi Gotthard, here’s a little secret: You can extract the workspace name and id from the authentication token :-) I am using this in my workspace auto-detection logic:
response = ... (authentication request to LeanIX)
token = response.json()['access_token']
token_body = token.split('.')[1]
token_parsed = json.loads(base64.urlsafe_b64decode(token_body + '=' * (4 - len(token_body) % 4)))
workspace_name = token_parsed["principal"]["permission"]["workspaceName"]
workspace_id = token_parsed["principal"]["permission"]["workspaceId"]BR Thomas
+3Hi Gotthard, here’s a little secret: You can extract the workspace name and id from the authentication token :-) I am using this in my workspace auto-detection logic:
response = ... (authentication request to LeanIX)
token = response.json()['access_token']
token_body = token.split('.')[1]
token_parsed = json.loads(base64.urlsafe_b64decode(token_body + '=' * (4 - len(token_body) % 4)))
workspace_name = token_parsed["principal"]["permission"]["workspaceName"]
workspace_id = token_parsed["principal"]["permission"]["workspaceId"]BR Thomas
+2That is a great hint
It would be great if LeanIX automations (and perhaps calculations) provided a variable containing this kind of information, similar to how the reporting SDK’s lx.init() returns a ReportSetup object that has all the workspace details, etc.
+3No, I don’t think it’s supported officially. If they remove it one day, I have other tricks how to auto-detect the workspace details, but token parsing is the easiest and cleanest way.
What use cases do you see for accessing workspace details in your automations and calculations? I usually build my logic so that it is workspace-agnostic and will auto-detect all of its context when I transport it to different workspaces.
In some cases, we stored configuration information in a dedicated hidden fact sheet type, but that’s more of a dirty hack than a clean solution ;-)
+2The most obvious use cases are looking for the workspace name do easily detect sandbox vs production. I don’t like to have to change the code from one workspace to another because of having something hard-coded / workspace-specific. I can also imagine wanting the code to be able to detect meta-model details, view details, etc. I suppose I think the closer the SDKs and APIs are across the different tools (report, calculations, automations), the easier everything becomes because patterns and methods you use in one can be used more easily used across the others.
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.