[FEATURE REQUEST] Custom Defined Trigger for Processors

Post Reply
Arthur
Member
Posts: 113
Joined: Sat Sep 09, 2017 11:58 pm
Location: Yateley, UK

[FEATURE REQUEST] Custom Defined Trigger for Processors

Post by Arthur »

Currently the only way to get a configurator / processor play its defined role / action is by an incoming file or certain amount of time passed / time interval actuated.
What if we could define a trigger for Hold Job, Assemble Job, Sort Job and probably multitude of other configurators, with an external trigger ie. change of state in other folder than the predeceasing to the processor (which effectively means an incoming job). Or an action that is taking place somewhere else in the flow, which at the same time could trigger an assemble job action in a different location (so that in this case the Assemble Job could have an identifier in type of the Portals, to which element then you could easily point to and thus trigger it from somewhere else).
Or maybe that if not triggered from somewhere else, it could alternatively be triggered by a specific job / file incoming ie.; dummy-trigger.txt and only when such file comes down the defined action is executed (if configured that way).

I guess this would help a lot. I would have a lot of use for this ...
Padawan
Advanced member
Posts: 358
Joined: Mon Jun 12, 2017 8:48 pm
Location: Belgium
Contact:

Re: [FEATURE REQUEST] Custom Defined Trigger for Processors

Post by Padawan »

What you describe sounds like the publish-subscribe programming pattern and it indeed currently not possible.

However, some of the usecases you describe do sound possible with Switch Scripting.

The external trigger could store the information somewhere.
For example:
- A field in a database
- Some information in the Switch Global Data
- Some file
- ...

Then you can check for this kind of information in the "subscribe" tool.
The hold job for example has a "Release condition" property in which you can setup a condition with variables or a script expression. Using this condition you can check where the triggered stored the information. You can check database values using condition with variables and database variables. You can check Global Data, files, ... using script expressions.

If you use the custom scheme in Assemble Job, then you can use a "Complete Condition" which works similarly to the "Release condition" in the Hold Job.

And the new webhooks functionality is also interesting in this context. You can have a http request in one flow (or a custom script) fire off a http signal and have a webhooks element (or a custom script) in another flow catch it and do something with it. The http request which triggers the task in Switch can even originate from something else than Switch entirely.

So I agree that a pure publish-subscribe method would be really handy, however I think that the usecases you are thinking about might already be possible at the moment. (Just a bit more work and likely to require scripting)
Arthur
Member
Posts: 113
Joined: Sat Sep 09, 2017 11:58 pm
Location: Yateley, UK

Re: [FEATURE REQUEST] Custom Defined Trigger for Processors

Post by Arthur »

Yeah - if one has got a scripting module.
But without scripting, engaging database etc. it is difficult (if at all possible) to for example release a variable number of jobs that are coming down in different moment in time to one location and are held within, based on a for example [Job.Name] pattern or PrivateData or anything similar.
As they all would require to be actioned (in this case released or assembled) at the same time, however appear in the location from which they would be assembled / release etc. in different time increments and their total quantity is unknown / variable each time.
One cannot leave the Release condition purely to discover 1 pattern and a timeout element set-up, as the time element has an impact on how the action performs. One time it may be a minute of a difference, the other time it may be 10-15. leaving orphan at say 15 unnecessarily lengthens the whole process. And on top of that there is a complete condition, which if not checked against the identifier to really make the action complete, would leave the task to a pure uncontrolled behaviour. If this at all makes sense.
So unless you have an option to tell the AssembleJob or Hold Job or whichever else of this type - 'execute the configured action now (and subsequently use the defined conditions)' by triggering it with an available custom trigger as and when required without an incoming file, the desired result will not be achievable.

I am using a lot of variables and metadata for all of those, yet I have a scenario where the result I am looking for, seemingly cannot be achieved without a custom trigger, other than an incoming job.
I am helping myself with shell / BAT scripts, which are created with Execute Command Friend and the use of many variables as to paths, file-name patterns, wildcards and so on, but this is inconvenient and more like a way round it, rather than a regular use of a tool that one would expect from Switch. Instead of being able to assemble jobs as and when needed, I am copying, moving them across hard coded folders with a commandline and BAT scripts when I need it, as the build in tools do not allow for this functionality.
Padawan
Advanced member
Posts: 358
Joined: Mon Jun 12, 2017 8:48 pm
Location: Belgium
Contact:

Re: [FEATURE REQUEST] Custom Defined Trigger for Processors

Post by Padawan »

I agree that it might be very hard or impossible without the scripting module.

I was just intrigued by your request because you seemed to describe something similar to publish-subscribe and I so far never had a case where I tried to implement that in Switch. Maybe I just never thought about it because I saw other ways to do it using scripting.
Post Reply