Configuring Alteryx Gallery API

[CSmith16]

Hello,

I am trying to configure an existing Alteryx Gallery API workflow the rest of our workflows use to call each other when a user selects data to run from the gallery. 

I created a new data selection workflow for this unit, Boston, and have changed the app id in the api workflow to the new workflow I want to call but it does not seem to be working and the DownloadData coming out of the download tool says the appid is null but it has an id?

{"id":"661fc4b4c43800006100711c","appId":null,"createDate":"2024-04-17T12:46:44.6937403Z","status":"Queued","disposition":"None","outputs":[],"messages":[],"priority":0,"workerTag":"","runWithE2":false}

 

I am using 661fc2c0f9e5dd0e0441a569 as the id in the request url so: 

workflows/661fc2c0f9e5dd0e0441a569/jobs

[CSmith16]

Just realized this, why is the Download data spitting out a different id? 

 

 

[SPetrie]

The ID in the response data is the job id, not the application id. Check the workflow results on the gallery, you should see a job that was run at the time you submitted the workflow run.

I could be mistaken, but I believe that appId is for responses involving chained apps where it is calling another app. 

[CSmith16]

I am trying to make a chained app. There is the 1st app from the gallery where the user selects the data to be ran and that will call the app in question. There would be nothing in the workflow results as I am an admin and checking the admin page and don't see the job running after the first was ran. We use this macro for other chained apps, and I figured I could just change the ID to the new workflow and have it call it the same as every other workflow. Those original API workflows were built by contractors, and they want to sell us something anytime we have a question. The 2nd app just isn't being called when I swap the request URL to use the ID from the job from the end of the url.

[SPetrie]

If you sign into gallery as the person whose API key and secret you are using, you should be able to see the run result by going to https://galleryaddress.com/gallery/#!job/661fc4b4c43800006100711c

You are getting a result saying that it is queued, so it looks like its adding the job to the queue properly.  That doesnt mean it ran successfully, but looking at the workflow result should give you more info.

You can also use the api to pull the results of the job run to see if it actually ran successfully or not.

The attached workflow should work for pulling the results of the jobid you give it.

It also has a branch that should be able to schedule jobs as well.

I use the v3 macros to authenticate since its easier. Its packaged with the workflow, but you should be able to get them from this link as well assuming your server is 21.4 or newer.

Hopefully that can help trackdown what may be going wrong.

[CSmith16]

So, the secret and Api key is the same for me, but I certainly didn't build the existing Api workflows. We use 2020.3 for our server version as well.

I'll definitely give that workflow a shot though but I am sort of out of office today as we have a volunteer event I'm attending so I will have to test this out on Monday.

Thanks for the replies and thanks for that workflow!

I am still trying to determine if this is even the best route to go. End goal is to allow for one of our units' journal entries / transaction summary to not post twice. All the other units use a standardized chained workflow. A user selects the data ad hoc from the gallery, and the rest is behind the scenes and they get an email saying what posted / didn't. The auto runs use a macro that checks a document called the posting record sheet, and if it has been posted already it wont select that data to be ran. And each workflow in the chain has its purpose, i.e. data selection, report builds, mapping, output, posting record, email. Problem with this unit is it was built back in 2020 and was designed to do all of those functions in the single workflow.

Problem with that is that it doesn't have any controls to stop duplicate journals, and I can't think of a workaround. I tried integrating that macro into the workflow sooner but it doesn't work if the date being ran isn't already on the posting record sheet. On top of the fact that the macro that creates the journals also spits out the file to our SFTP partner every run. 

Ideally, I want to make this function like the other units and use a chained workflow to separate all the workflow functions.

[CSmith16]

As stupid as this is,

I got this to work by using the API Documentation rather than pulling the job ID from the URl. Which is weird why it's deciding to work now seeing as its the exact same ID on the gallery and the API documentation, so it would have worked before as well if it works now.