- This topic has 3 replies, 2 voices, and was last updated 1 year, 7 months ago by .
-
Posts
-
I’ve trying to create some automation that uses BatchPatch’s “run as a service” capability. Every 2 days, I need to process a new .bps file. To do this, I swap-out the .bps file that is already running under the service by (1) stopping the service, (2) copying the old .bps file to another location for further automation, (3) copying a new .bps file (that I’ve created via some other automation) over the one that the service was previously running (with the same name), and (4) restarting the service. This essentially “tricks” BP into running my new .bps file without user intervention.
While the .bps file is running in the service instance, it doesn’t (by design) show any results in the .bps file itself. The only way you can see those results is by using the BP service viewer. Normally, you would write the results to the file by using, “remove grid from service instance” or by dragging the grid from the service instance viewer into the main BP window. This will display a confirmation dialog saying that it will save and close the grid (which lets you load the grid and view the results).
However… since I am simply stopping the service (and copying the .bps file to somewhere else for more processing), will the results be present in that .bps file? Asked another way… Will stopping the service SAVE the results into the file before the service terminates? …or will my result information (patching success/failures) be lost to the great bit-bucket in the sky?
All grids in the service instance are auto-saved every 15 seconds as well as when the service stopped. That said, while what you are doing sounds like it should be ok for now, I can’t make any guarantees about the behavior that you can expect since you’re doing something that isn’t directly supported in the app. You should definitely test it to make sure it behaves the way that you want and are expecting. Also note that while you might get it working just fine for now, I also can’t make any guarantees about whether or not it will continue to work in future versions of the app (again, simply because you’re doing something that is not directly supported in the app, and it’s possible that we could make a change in a future version that breaks your existing automation).
-Doug
No problem. If you observe anything that is inconsistent with what I said above, let me know. Thanks.
- You must be logged in to reply to this topic.