We are in the final days to enter our Data and Analytics - "What's your why?" raffle with SparkED!

Reply with your "why" in text/video format to our forum post by January 28 to be entered! 

Alteryx Designer Discussions

Find answers, ask questions, and share expertise about Alteryx Designer.

Chained Alteryx Analytic Applications Concurrency Issue

11 - Bolide


Hello everyone. I am strugling with a large conceptual problem in Alteryx that I am hoping the community can help explain better to put my mind at ease :-)


Lets say I build a chained application for the following scenario..  A user needs to select a single client from a list of clients in a database, and then a query against the database needs to return a list of loan numbers for that client.  Once again the user selects the loan he wants to look at and the workflow does its work.


I could accomplish this by having the first workflow return a dropdown box for all of the clients from the database.  I could then write whatever client they choose to a alteryx file (YXDB)  and have workflow #1 call a second workflow that would use that YXDB file to provide a secondary drop down selector.



Isn't concurrency a problem here

My concern is as follows. If I make this an analytic app and user A kicks off the workflow it will create the YXDB file... Say use B then kicks off the workflow before user A's app could read from the YXDB file...  Wouldn't user B'd workflow then overwrite the YXDB file and user A's workflow results be corrupted?


Would this only happen if you hardcoded the YXDB file onto a network path (or C drive on the server) and alterYX base has a work around for this if you don't hardcode these results somewhere?


I would just like some more color around this problem if at all possible; as it is a major mental roadblocker for me being able to use linked applications in general in AlterYX.  (I have looked but haven't bound any documentation that specifically addresses this concern, but if I missed it please just let me know!) 



As always thanks everyone, this community is incredibly helpful! 

12 - Quasar

You could write to temporary files.  You could also just have the data stream populate the selections directly without writing to files.

11 - Bolide

Hey jason.  How would one go about writing to a temporary file and then having the next analytic app in a chain know which temporary file to read from?  I didn't realize this was an option when using chained apps.  Actually without hardcoding a file location I don't know how to share data between chained apps at all, so I am very curious at to what you mean here.


Unfortunately I'm not sure I follow you on this one.

You could also just have the data stream populate the selections directly without writing to files.


Would you be able to elaborate what you are referencing here? 



11 - Bolide

Hello Jason.  Sorry I should clarify my question.  Are you saying that if a secondary chained all reads from %temp%\  then it knows which temporary directory the first app in the chain wrote too?


My concern was (and I think I might have been wrong based upon your comment)....


The first app create a temporary directory, and then the second run of the first app creates another temporary directory.   Then when the second app in teh chain is kicked off it just pulls from the last created temporary directory...


I think your answer implies this isn't true, and somehow the secondary app knows which temporary directory the first application created?


If thats true that fully alleviates my concern :-)


Hi @bsharbo

The standard design for chained app dynamic YXDB-driven questions looks like this:

  • In development, set your default YXDB paths local to your app
  • Include the default YXDBs as assets at publish-time
  • When the chained app runs, the default YXDBs will be overwritten with the new version. (Your generated YXDBs should have the expected file name, not a temp file name)
  • Every app run produces a full temp package, and any locally-written files write into that temp package. You never need to worry about the actual location of the temp package on the file system, nor collisions between users if you've set it up according to above.
  • Writing to a specific location on the file system should only really be considered if you need to share YXDBs across users/runs, or you're generating/maintaining a YXDB inventory on the file system. But as you've noted, you could very well run into certain conflicts.


Also consider that some dependent question scenarios can be solved with a custom Tree rather than a dependent yxdb-driven lists. In those cases, you might be able to avoid chaining.  


One other little "gotcha" to keep in mind is that the "Rerun" functionality consumes the original YXDBs, not the dynamic ones. 


8 - Asteroid

Hey @DanH


Would you be able to share with me a small example with two chained apps? I need exactly the same solution just cannot understand where I can write data from first app which would be used in other apps.








Hi @ignas. Sure thing. I've attached a simple example. Step1.yxwz allows you to select a state, then generates "counties.yxdb" based on that state selection. Step2.yxwz reads counties.yxdb in order to produce a report. Note that all the files are just referenced without path, meaning that they'll read/write within the app package at execution time. Also note that you define the next step in the chain within Interface Designer Pane > Properties icon > "On Success - Run Another Analytic App". You may have many steps in the chain. 


I hope this helps!