portal callback

[danb]

I found portal app when looking for best practices and love it. Well, the idea of it.
I was playing with it and got it to work following the supplied sample.
But if I'm sending a csv file with callback included to a smartstream flow and the smartstream flow returns a PDF then how does the PDF inherit the csv callback for correct routing?

sorry in advance if this is a lame question

[gabrielp]

Magic! Well, not really.

The callback is just private-data (PD is like a key-value store in Switch). You write private data (as a key, lets say "MyKey") to the channel you want to route the job back to (lets say "X"). Then, in your "functional flow" (the flow that the job is sent to) you have it return to the channel of "MyKey" and it comes back to "X". If you make a flow tomorrow that wants to use that functional flow (called "Y") just send jobs in there with "MyKey" set to "Y" and they'll come back as expected!

So, if your functional flow is producing some product that isn't the original job (like a PDF) then its up to you to get new job to have the same PD as the old job. How do you do this? There's a bunch of hacky ways like naming it a certain way and then stripping off the PD value off the name and restoring it. But my preference would be to assemble the jobs, which should allow you to get the PD values of both jobs, you can then split them again and discard what you don't need. Another way of doing this would be to use the app that allows you to set CSV files as databases (Dwight made this) and you can do a DB write and lookup to get the PD value back. But... you may find that the streamstream app keeps your PD from the input job into your output job (I don't recall).

[gabrielp]

Also, I haven't used Switch in a while so it may be easier to do this now. But at the time, it wasn't really easy to see the PD values of any old job. This script outputs a file so you can see them easily https://github.com/open-automation/swit ... ket-export