Enfocus Community

Switch Portals
Route jobs in a Switch flow without a direct connector.

Description:
You can send jobs around within a flow, keeping logic better-organized and easier to read. Pass jobs between flows without having to manage non-automanaged folders or requiring access to the local file system. If you build or share flows with others, feel free to break up your flow logic while still making flow distribution simple. Flows can now be connected through an abstracted method which does not rely on prior configuration of the local filesystem.

Usage:
This repo contains two scripts: an incoming and an outgoing portal. Portals are multiplexed by channels (which you select in the script) so you can have multiple sets of portals within a single flow. Portals also have a choice of scope: flow, program, or global. If an incoming and outgoing portal share the same scope and channel, jobs will be routed between them. Metadata and job ticket information is maintained between portals as well.

Flow element properties:
Scope
This property namespaces your channels, allowing you to restrict or allow portals to work within or between flows.
Channel
This property multiplexes portals to allow several portals within your flow, or in other flows, to work without conflict. Incoming and outgoing portals which share the same channel and scope will exchange jobs.
Debug Warnings
Optional flag to send debug messages to the log as warnings.

Get it here:
https://github.com/open-automation/SwitchPortals

Watch the Enfocus Safari webinar "Thinking with portals":
https://www.enfocus.com/en/virtual-safa ... th-portals

Personally I don't see the benefits for me, since all IT related stuff is going through me so access to everything

Just replying I really like the out of the box thinking you are doing over here!

I expect that you tried to set the end folder settings to Strip Unique Name: No

Didn't that work?


Jan

jan_suhr wrote:I expect that you tried to set the end folder settings to Strip Unique Name: No

Didn't that work?

Yeah, that works fine. It's just an annoyance that you have to create and maintain another non-automanaged folder. If you have a need for 30 of these folders to pass around jobs, you'd have to create 30 folders somewhere and ensure you never rename them, then make sure you link up to them. You might not have access to the filesystem the Switch server runs on (which is the case for me). With this script, you select a non-automanaged folder once, then never have to do it again. Additionally, it provides some context into what's going on since passing files within different parts of the flow the standard way just looks like another folder. So yeah, it's not really a new feature, just a fun way to do it a little easier.

Here's an example of a flow I recently worked on where I utilized this:

You can now pass between flows with the Scope property. Leaving the default value of "Flow" will namespace your channels to within your flow, keeping you from accidentally passing them to other flows.

Major overhaul today. https://github.com/open-automation/SwitchPortals

- No more need to set the etherPath. Now it uses the ScriptData folder. Thanks for the tip, Ted from ASI.
- Portals now pack and unpack, meaning all metadata is preserved. I've tested external datasets and private data, but I'm also maintaining jobstate, etc... Thanks to Dwight from Apago for help with writing the job ticket data as a JSON dataset.

Update today. Handling job ticket info a different way now since the old way was causing bugs when you would pass jobs with private data with special characters. Now, special characters (like HTML) are handled fine passing between portals.

This new way is incompatible with the old way, so I've named the new scripts v2 so you don't update them by mistake.

Another update today that further normalizes and validates property values. Program scope introduced, so you can now namespace your portals for a specific program or set of flows, without opening it up to the global scope.

Fixed a serious bug related to the v2 set I released (thank you lombert for the bug report!). The latest copies on GitHub are working fine now.

I really like the idea of using portals and I've been doing some testing. That makes me wonder which metadata is actually carried across a portal? I see that the information in "Job state" is still there after sending a file via a portal, but "hierarchy info" and "email addresses" are not.

I have used your script for writing Privat data and this info is still there after using the portal, so I was just wondering which of the metadata-fields will be preserved and which will not?

Terkelsen wrote:I really like the idea of using portals and I've been doing some testing. That makes me wonder which metadata is actually carried across a portal? I see that the information in "Job state" is still there after sending a file via a portal, but "hierarchy info" and "email addresses" are not.

I have used your script for writing Privat data and this info is still there after using the portal, so I was just wondering which of the metadata-fields will be preserved and which will not?

Everything should be, but I haven't buttoned up some of the small details yet. If you find other fields, please let me know. I will put in a fix for this ASAP. I've opened this issue on your behalf: https://github.com/open-automation/Swit ... s/issues/7

To answer your question with specifics: all datasets + the job ticket (job state, private data, etc...) are carried across. Portals only works if we keep our variables, so as a user you should expect everything to be maintained.

Aon an unrelated note, consider registering to my Virtual Safari session on Portals: https://www.enfocus.com/en/virtual-safa ... th-portals

An example of linked flow distribution: https://drive.google.com/file/d/0B9ciRz ... sp=sharing

Import that group and be amazed that all of the flows work in concert without any user configuration.

Everything should be, but I haven't buttoned up some of the small details yet. If you find other fields, please let me know. I will put in a fix for this ASAP. I've opened this issue on your behalf: https://github.com/open-automation/Swit ... s/issues/7

Thanks a lot, Gabriel. I've mad a few extra comments on GitHub.

Thanks for that. The latest update carries over hierarchy, email, and username fields.

There's some stuff I'm not sure if I'll ever be able to restore: job origin for example.