In the System Manager, we find the applet Service Manager used to monitor and control services running in SimCorp Dimension. We will take a closer look at the usage of this tool in this blog and provide some tips you might not be aware of. The service control utility ScdSvcCtl.exe used to manage the service platform and its services from a command line tool will not be discussed in this blog, but we plan to return with a later blog to discuss this. We can mention that this tool allows you to do much the same thing as the Service Platform GUI, but without login into SimCorp Dimension.
Once you have opened the Service Manager in the System Manager you can toggle different views: a pivot view, a grid view, an automation state, and an agents view.
In the Services Pivot view, the default gives you a view of services running on each physical server. Unless you are keen on looking at server utilization, this might not be the best view. We suggest you right-click on the header and choose ‘Select Fields’ and remove the field selected under the column field. Doing this, you will see one column showing the number of a given service running. This makes it easier to select a service, for example, the Message Queue, view logs, stop services, and just simply see how many are running. Another view that can come in handy is to select ‘Management mode’ in the column field. This allows you to see which services have been started manually and which have been started automatically via the model (defined in the Service Dependency Editor) and is useful to check any services that have been started outside of the automation model. Remember you can toggle between different setups in the System Manager using the layout save option in the lower right corner of the window.
The Automation State view is useful to give a graphical overview to see any issues in the platform and provide an overview while the Service Grid simply provides the same details in a basic grid/excel-like view.
The Agents view provides the utilization of the servers running such as CPU usage, memory available, and how many agents there are running on each server. In addition, a load index can be used to indicate underutilization or potential problems with overutilization.
When starting a service, rather than scroll through the list, you can click on one that is already running in the services pivot, and when pressing Start, in the pop-up it will automatically select this service. In the same pop-up, if there is any underlying configuration you can select a different one or run the same proposed; and under agent rather than selecting a specific one, it is often best to let the system decide to get the most optimal utilization.
If you need to restart a service, and if your platform has automation enabled (and the service in question is part of the model running), you only need to stop the service(s) in question. The model will automatically know to restart it. If you have a service running in an automation state and you don’t want it to restart, you can put a block on it. Select Blocks, and in the pop-up press New and enter the details of the service type and if available also the configuration. Then, in set up, remember to press save and this will stop the service from running and restarting.
When running a test, you frequently need to stop and restart services. For example, the Message Queue Service will remember the latest use of a Data Format Setup (DFS) to avoid having to reload the configuration of the DFS every time you run a message through. This is great in production where changes are controlled and happen rarely, but in development, if you change a DFS, the change will not be sent to the MQ server, and it will use an old version of the DFS. So, remember to restart services when you make changes to the configuration. These restarts leave a record in the service platform; you can remove these stopped and failed services by selecting Clear All and choosing which types of service to clean up.
We mention the Service Dependency Editor a couple of times. This is where you define which services should be part of the automatic model running and if there are any dependencies amongst others. You can toggle the automation mode: in Production, you fix the setup and cannot change anything. In Maintenance mode, you can change the model (provided you have more than one model defined), and you can also switch off automation and rebalancing. It is also under Maintenance mode you have the option to suspend or restart the platform. A restart is useful if the system services become unresponsive.
This was a quick highlight of some of the main features of the service platform. We hope you found this useful and as always, please leave a comment. And remember to subscribe to our updates if you are not already doing.