Alteryx Server Discussions

Find answers, ask questions, and share expertise about Alteryx Server.
SOLVED

Expose Alteryx Gallery AppID within executing job

bkclaw113
9 - Comet

Is it possible to have a job executing on the gallery be dynamically aware of its gallery AppId?

 

I have an application that requires me to log usage to a central repository and I need to know what workflow used my process. In designer I can use the [Engine.WorkflowDirectory] and [Engine.WorkflowFileName] variables to uniquely identify a workflow, however when that same workflow is saved to and run from gallery a unique staging folder is created each time it is run so every run appears to be a new unique workflow. If I were able to dynamically access the gallery AppID (or URL)  then I could use that in place of the Directory and FileName.

 

I am hoping there is something like "__cloud:UserId" only maybe "__cloud:AppId" (I tested and unfortunately __cloud:AppId did not return anything)

 

I have considered embedding a gallery API call into my process that would identify the currently executing jobs and infer which from that returned list was applicable but that seems very heavy, and I imagine that many organizations either do not have the API's enabled, or would be unwilling to allow a generic user API key to be embedded within a shared macro.

6 REPLIES 6
ArnaldoSandoval
12 - Quasar

Hi @bkclaw113 

 

Please check with your Alteryx Vendor, as Alteryx already have tools generating this data, check with them.

 

Arnaldo

bkclaw113
9 - Comet

Thanks @ArnaldoSandoval, what tools have you seen that have this type of functionality?

ArnaldoSandoval
12 - Quasar

Hi @bkclaw113 

 

It is known as the Alteryx Server Usage Reporting App, you can Google it, Google returns 400K hits, now I visited some of those hit and posting their links on this reply.

 

 

I had seen the ASUR output, but I don't have it available at the moment, it is very rich, and could be helpful.

 

Hope this helps,

Arnaldo

 

bkclaw113
9 - Comet

Thanks for the clarification, unfortunately though this is not what I am talking about. I am able to look at either mongo or the Gallery API's to find out information about other jobs that have previously run. The problem that I am trying to address is how to get that Gallery AppID for the job that is currently executing to be exposed to that job itself.

 

If you imagine that the last tool in your workflow is an email tool, and in that email tool you want to configure it to send whoever ran the job (on Gallery) an email where the subject line is the AppID that is essentially what I am trying to do. I can use "__cloud:UserId" to tell the job who to send the email to, but am trying to figure out how to get the Gallery AppID within the workflow so that it can be pass to the email tool.

bkclaw113
9 - Comet

I did some more research looking into using the Gallery API's to get the AppID, but cannot find an endpoint in the V3 API's that looks like it will provide a list of all currently executing jobs.  There is GET /v3/jobs/{jobId} but the jobId is required which I would not know or have access to. Then there is GET /v3/workflows/{workflowId}/jobs which requires you to already know the workflowId.

 

Is there an endpoint that would give me a list of the currently executing jobs?

 

The only way I see is to use the workflow name as a parameter for GET /v3/workflows and if I only get 1 workflow returned then that is what I use, but if I get multiple workflows then I would need to call GET /v3/workflows/{workflowId}/jobs for each returned workflow until I find the one that has a status indicating it is running.

bkclaw113
9 - Comet

It is clunky, but I can confirm that the approach mentioned above does work (Get Workflow ID's by name, and then for each workflow use jobs endpoint to find job that has status of "Running".

 

Note this would not work if for some reason 2 workflows with the same name were both running on our environment.

 
 

See attached picture of gallery log with the AppID in the URL matching the AppID returned in the log.