Completed
Run Agent as Service
Anyone able to get the On-premise agent to run as a service? I tried using Srvany.exe tool and it runs, but the flow doesn't work. If I run as Application, it works. However, I need to make sure it is always running even if I'm not logged in.
0
Comments
The new version of the agent executable is ready for you to upgrade and run as a service. Complete instructions are here:
The only thing you have to keep in mind is to launch the agent after it's installed and then select the service option (Step 4).
We hope it's worth the wait, Damon Betlow, Troy Turley, Wade Shelton & RSCS SaaS Admin. Happy to hear your feedback and continued suggestions.
The local on-premise agent is pretty worthless, if it can't be set it and forget it.
Damon - Did you figure anything out here? I'm looking at the same issue. I have it set up to run from Task Scheduler when the machine starts, but the process keeps dying... without logs.
I might try to create a powershell script to monitor for it once per minute and see if it's still running, or might use something like SrvStart to run the exe as a servce
I also used Task Scheduler as a workaround. I set it to start at startup, as well as daily. This has been working for us, but it hasn't randomly quit (that I know of), but the scheduled flow runs . I was just more concerned with it not getting restarted after reboots... Make sure you are using the latest agent. We are using 1.4.8.
Damon -
I'm trying to avoid Task Scheduler due to shortcomings. Some of the flows involved here are mission critical, and I can't afford for the agent to go silently offline, and don't want get into scheduling/race conditions where the process restarts / re-spawns in the middle of a flow.
So... I've tried a few things.
First was sc.exe from Microsoft. Often works great, but has one flaw... no GUI's allowed. Since the agent runs from a GUI (and I can't find any documentation on how to prevent that), that path fails. SC can create the service, but then it won't start.
The second (where I've had some success) is using an open-source tool called nssm (Non-Sucking Service Manager), that I've used in the past to start command-line applications as services. It's a service wrapper (it runs as a service, calls your executable, and handles/suppresses interactive error messages and GUIs). It's working fine in test, but it's also an open-source, unsupported tool in a production environment. Doesn't give me warm fuzzies.
Looking at ServiceMill from Active+ Software. Will see how that pans out.
Bottom line here, though... Celigo needs to convert this thing to a windows service. The application GUI doesn't provide much, anyway...
Hi everyone,
Thanks for sharing ideas with each other on this! We do hope to enhance this later in the year. For right now, the recommended practice is to use a small and dedicated windows server and to run the agent in the background, then to not use the machine for anything else. This should run flawlessly, and we ourselves use the agent in this manner for our own Celigo business flows.
Hi everyone,
Good news! We do have this planned for our November release. We'll post more info when it's ready. Thank you so much for your invaluable feedback in helping us prioritize what would best improve your integrator.io experience!
Terrific!
when is the november release going to deploy?
If the agent is deployed on a small and dedicated windows server and runs in the background, and the machine is not used for anything else, how is it leveraged by flows on other servers? This topic isn't covered in https://docs.celigo.com/hc/en-us/articles/360004081771-Integrate-data-through-firewall-with-on-premise-agent
Is there a knowledge article that supports the best practice mentioned above?
Hi Troy Turley,
Thanks for letting us know about this need! I'll check on this question. We don't have an exact date yet on the release.
Hi Troy Turley,
The November release is currently scheduled for next Wednesday, Nov 11.
The integration flows themselves are orchestrated by integrator.io in the cloud, but integrator.io uses the on-prem agent to effectively proxy import/export requests to the applications that are behind the firewall. As the doc you linked mentions, the agent just needs to be on the same network as the applications that are participating in the flows. I believe that's what the doc covers sufficiently, but please let us know if anything is still unclear.
Regards,
Matt
As Celigo does for their business flows, I'm going to spin up a small and dedicated windows server to run the agent in the background, then not use the machine for anything else. Are there any specifications you can share? They're needed for my IT team. Thank you.
Troy Turley, the agent is pretty lightweight and is not memory, CPU or IO intensive, so a minimal machine (one capable of running the Windows OS itself) should be sufficient.
Thanks,
Matt
Please sign in to leave a comment.