switch-inject-lite
Posted: Mon Aug 15, 2016 7:36 pm
switch-inject-lite
The purpose of this script is to provide a low-risk and contextual alternative to the Inject configurator.
While the stock Inject configurator is extremely powerful, for many operations, it poses a significant risk. The ability to copy and remove a remote file (which may be a variable) is extremely dangerous. The target variable could resolve incorrectly causing the destruction of Switch's own backing files, or other sensative files. In some cases, users have reported using the "Job repository" method of Inject, where "Job name" property resolves to null, which results in the entire repository being injected (and removed).
The stock Inject configurator assumes that target jobs exist. If you aren't sure where the target job is, you have to send your incoming job into several incoming jobs, expecting all but one to fail. This results in routing out these non-failures from problem jobs, which is undesirable.
https://github.com/open-automation/switch-inject-lite
Use case: production file request system
This flow handles production file requests from our customer web portal. The web portal creates a simple XML file which Switch watches for. Then, Switch takes the job number from the XML file and attempts to find the file in one of 3 locations: live jobs, archive 1, or archive 2.
1) The first problem is that we don't know where the backed up files actually are. That's because we dynamically move files from the live jobs folder to the archives 1 and 2 as work is completed. So with the stock Inject, we have to inject against all 3 directories every time, which is quite a bit of overhead.
2) The second problem is, since the files are in 1 location but we have to inject against all 3, we now expect at least 2 failures with every successful retrieval. That means we have to route jobs out of problem jobs (since they are not truly problems). This adds junk to our log and is generally confusing.
3) The third problem is, Inject assumes the target job exists, and it sends the file to problem jobs if it does not. Because of this, we cannot run the injects in sequence and we cannot tell if all of them had failed (if we could not find any production files). The only way to accomplish this would be to assemble the known failures out of problem jobs, then send an email if there were 3 that matched the same job number, which again is routing business logic out of problem jobs (a known anti-pattern).
4) Lastly, the Inject configurator has the ability to remove the target file if the option "Delete after injection" were set to "Yes". It's easy enough to set this to "No", but it is very easy to scroll on the mouse while hovering over injector properties which changes them. There have been cases where injecting a null job name on a job repository can inject the entire repository. So there is a minor risk of deleting our entire live jobs or archive volumes if that were to happen.
A redesigned flow using switch-inject-lite addresses these concerns (as well as relies on a functional flow to gather metadata).
1) In this flow, we only inject against the next directory if the previous had failed, since we are making use of the traffic-light-style connector.
2) We are not sending any injection failures into problem jobs. Instead, they are routed via traffic light, keeping our business logic in the flow and our log and problem jobs folder reserved for true problems.
3) switch-inject-lite does not assume the target file exists, therefore we can route the injects in sequence. If the final inject in the sequence fails, we know that the files could not be found in any location and we can handle that business logic easily.
4) switch-inject-lite cannot delete files after injection, therefore there is no risk of any accidental deletes.
Scripts used:
- switch-portals
- switch-variable-assert
- switch-private-data-write
- switch-inject-lite
- switch-aws
The purpose of this script is to provide a low-risk and contextual alternative to the Inject configurator.
While the stock Inject configurator is extremely powerful, for many operations, it poses a significant risk. The ability to copy and remove a remote file (which may be a variable) is extremely dangerous. The target variable could resolve incorrectly causing the destruction of Switch's own backing files, or other sensative files. In some cases, users have reported using the "Job repository" method of Inject, where "Job name" property resolves to null, which results in the entire repository being injected (and removed).
The stock Inject configurator assumes that target jobs exist. If you aren't sure where the target job is, you have to send your incoming job into several incoming jobs, expecting all but one to fail. This results in routing out these non-failures from problem jobs, which is undesirable.
https://github.com/open-automation/switch-inject-lite
Use case: production file request system
This flow handles production file requests from our customer web portal. The web portal creates a simple XML file which Switch watches for. Then, Switch takes the job number from the XML file and attempts to find the file in one of 3 locations: live jobs, archive 1, or archive 2.
1) The first problem is that we don't know where the backed up files actually are. That's because we dynamically move files from the live jobs folder to the archives 1 and 2 as work is completed. So with the stock Inject, we have to inject against all 3 directories every time, which is quite a bit of overhead.
2) The second problem is, since the files are in 1 location but we have to inject against all 3, we now expect at least 2 failures with every successful retrieval. That means we have to route jobs out of problem jobs (since they are not truly problems). This adds junk to our log and is generally confusing.
3) The third problem is, Inject assumes the target job exists, and it sends the file to problem jobs if it does not. Because of this, we cannot run the injects in sequence and we cannot tell if all of them had failed (if we could not find any production files). The only way to accomplish this would be to assemble the known failures out of problem jobs, then send an email if there were 3 that matched the same job number, which again is routing business logic out of problem jobs (a known anti-pattern).
4) Lastly, the Inject configurator has the ability to remove the target file if the option "Delete after injection" were set to "Yes". It's easy enough to set this to "No", but it is very easy to scroll on the mouse while hovering over injector properties which changes them. There have been cases where injecting a null job name on a job repository can inject the entire repository. So there is a minor risk of deleting our entire live jobs or archive volumes if that were to happen.
A redesigned flow using switch-inject-lite addresses these concerns (as well as relies on a functional flow to gather metadata).
1) In this flow, we only inject against the next directory if the previous had failed, since we are making use of the traffic-light-style connector.
2) We are not sending any injection failures into problem jobs. Instead, they are routed via traffic light, keeping our business logic in the flow and our log and problem jobs folder reserved for true problems.
3) switch-inject-lite does not assume the target file exists, therefore we can route the injects in sequence. If the final inject in the sequence fails, we know that the files could not be found in any location and we can handle that business logic easily.
4) switch-inject-lite cannot delete files after injection, therefore there is no risk of any accidental deletes.
Scripts used:
- switch-portals
- switch-variable-assert
- switch-private-data-write
- switch-inject-lite
- switch-aws