Overview
While using Portals for the past week or so, I've come up with some new design patterns. One such pattern is what I'm calling "Portal Callbacks". In essence, this allows you to easily turn a flow into a function, then pass jobs into it, routing the job to any flow when the callback is called. This isn't groundbreaking, but with Portals you can send a private data variable as the return channel, allowing you to send the file back to an infinite amount of flows without complicating the function flow with several outputs.
Flows as functions
If you find the need to reproduce flow logic for use in other flows, turning a flow into a "function" would allow this behavior. Programmers will understand the concept of a function which take a callback parameter. Pretend that your flow (Example Flow) invoked a function, which with a parameter, would tell the function where to return the result [ yourFunctionFlow(returnLocation); ].
Provided example
I have created an example set of flows with this pattern in use. Since this is using global scope portals, no configuration is needed. All of these flows will work together on any system which has the scripting module.
The entry flows (Program A and Program B) take files and send them into a function flow (Rename Function). Rename Function simply adds a prefix to the job file name and returns it back to the respective program flow. The Rename Function flow therefore requires that the return channel be set (which is a private data value), so an Assert script ensures that "Rename Function Return" is not blank.
Rename Function is now completely modular and can be re-used and improved upon, separate from the Program A and Program B flow logic. When we add Program C (D, E, through Z eventually) we can rely on Rename Function to do its job and not recreate the wheel each time.
This is a very simple example. Consider a function flow that gets metadata from a database or archives files.
Example flows download:
https://drive.google.com/file/d/0B9ciRz ... sp=sharing
Example flows documentation:
https://www.googledrive.com/host/0B9ciR ... 3htVW1qeEU
https://www.googledrive.com/host/0B9ciR ... HhiSXBGWjg
https://www.googledrive.com/host/0B9ciR ... TVyT3JZODg
Scripts used:
https://github.com/open-automation/SwitchAssertNotBlank
https://github.com/open-automation/SwitchPortals
https://github.com/open-automation/Swit ... rivateData
Portal Callback Pattern
Portal Callback Pattern
Last edited by gabrielp on Thu Jun 30, 2016 9:30 pm, edited 2 times in total.
Free Switch scripts: open-automation @ GitHub
Free Switch apps: open-automation @ Enfocus appstore
Want to hire me? I'm looking for my next gig. Contact me on LinkedIn or via email.
Free Switch apps: open-automation @ Enfocus appstore
Want to hire me? I'm looking for my next gig. Contact me on LinkedIn or via email.
Re: Portal Variable Return Pattern
Very interesting... Now I can't help but wonder: are Switch flows Turing complete?
Re: Portal Callback Pattern
Updated files. Included a more complex rename function, using portals v2 with program ID, and using new version of variable assert.
https://drive.google.com/file/d/0B9ciRz ... sp=sharing
https://drive.google.com/file/d/0B9ciRz ... sp=sharing
Free Switch scripts: open-automation @ GitHub
Free Switch apps: open-automation @ Enfocus appstore
Want to hire me? I'm looking for my next gig. Contact me on LinkedIn or via email.
Free Switch apps: open-automation @ Enfocus appstore
Want to hire me? I'm looking for my next gig. Contact me on LinkedIn or via email.