Hi,

We install CCE, SPM and all aplications on Windows as services, as is the normal practice. But when we use the CCE UI to start an IS, the service is not started, instead an independant process is started. Are there any plans to correct this?

Thanks.

CC starts IS in the way it was installed: service or app. If you installed IS as app, CC will start it as app.
Is CC and IS 9.8 or older?
How IS was installed: installer or CC?

Hi Sergei,

We are using IS 9.7 and CC 9.7
I installed the IS using the Installer in command line.

Test I did:

1- Application not running
2- I start the service for the IS : it works fine. The CC UI shows that IS is up.
3- CC UI, I do Lifecycle - stop on the IS : application stops, service is stopped (all good)
4- CC UI, I do Lifecycle - start on the IS : application starts, but uses my personal account?! - not the one configured in the service, and the windows service remains stopped (not good)

I used my personal account to install the IS, maybe it’s related? Also good to note, after installation I also modified the service name : I unregistered the service, modified wrapper.conf and re-registered the service.

Thanks.

Looks like you’ve done some manual changes to the service registration which are likely not in sync

To confirm:

1. Shutdown IS, both service and app
2. Open installdir/profiles/IS_default/bin/ folder and run startup.bat. This is what CC (using SPM) runs when you click Startup menu in CC Web UI.

If you see IS app starting instead of service, then the IS_default profiles scripts are configured to run IS as an app.

To make them run IS as a service open custom_setenv.bat in the same folder and ensure USE_WRAPPER=yes and STARTUP_MODE=service
…

if “%USE_WRAPPER%”==“” (
SET USE_WRAPPER=yes
)

if “%STARTUP_MODE%”==“” (
SET STARTUP_MODE=service
)

Then try startup.bat again. It should start IS as a service

As suggested, I ran startup.bat and it started as an application and not as a service. Then what I did is compare the files from my installation having the problem vs a brand new untouched one, and I discovered in the setenv.bat file that the service name was also specified there, in addition to wrapper.conf, but with the old name. So I modified it to reflect the new service name and now it’s working properly.

So the question is, is modifying wrapper.conf and setenv.bat the correct procedure to modify the service name, otherwise what is it? Ideally, the Installer should allow us to specify a name for the service or there should be a way to modify it with Command Central.

Service/daemon management is on the CC roadmap but not a high priority item right now.

The service names (and daemons on UNIX) follow standard SAG/webMethods convention to ensure multiple installations on the same machine do not collide.

What’s the main reason for you to change the service name?

The service name is very useful to see at a glance what the application is used for.

For example, by default if you install 5 IS on a Windows server, you’ll get something like this:

Software AG Integration Server 9.7 (default)
Software AG Integration Server 9.7 (default)(1)
Software AG Integration Server 9.7 (default)(2)
Software AG Integration Server 9.6 (default)
Software AG Integration Server 9.6 (default)(1)

Difficult to know what each one does. We like to rename the services to include additional info like the role of the IS and the primary port:

SAG Integration Server 9.7 (ESB-DEV1 - 17555)
SAG Integration Server 9.7 (ESB-ACC1 - 27555)
SAG Integration Server 9.7 (EAI-DEV1 - 37555)
…

This way it’s much easier to support.

If you’re using CC, you don’t have to look at services.
You can rename your IS instances (display names) the way you want and even assign them different icons.

That’s a good point. But currently (and for the next year), many of our IS will still be v8.2, so not compatible with CC. After that, I’m still seeing a use for descriptive service names. Even with an administrative console (CC for example, could be something else), there always comes a time when you need to log into the server to investigate what’s going on, and at that time it’s useful to have descriptive service names.