Search

Home

Home

Automatic Invocation Server

Automatic Invocation Server

Automatic project invocation is managed by a server application that is an integral part of the GRAVITY.INTEGRATION package.

Depending on the environment requirements and user preferences, the server can be run in one of two modes:

  • as a Windows service,
  • as a user interface application.
❗
Only one server application can run at a time. You have to choose whether to use GravityTriggerRunner or the Windows service.

Server as a Windows Service (gravity.integration service)

The service is installed in the system together with the GRAVITY software. It does not have a graphical interface, but you can monitor the execution of triggers through log files that are generated daily.

Log files are available by default in the following directories:

  • C:\ProgramData\Caffeine Minds\Gravity\ServiceLogs— contains the service operation log. It includes detailed information about service startup, trigger execution, and invocation results.
  • C:\ProgramData\Caffeine Minds\Gravity\ServerLogs — contains the web server log with information related to hosting defined WebService triggers.

By default, the service is installed in manual startup mode and remains disabled.

image

You can change this in the service properties, in the Startup type field.

image

The recommended startup mode for the service is Automatic (Delayed Start). Lowering the service startup priority helps prevent errors caused by the unavailability of other Windows components (e.g., network readiness) or by limited access to external systems that the service connects to during startup (such as databases — Automatic Invocation via Database Notification Mechanism, message brokers — Automatic Invocation via RabbitMQ Message Reception, and other servers), especially when they are hosted on the same server.

The service is intended for use in a production environment, but it can also be used in development mode without restriction.

❗
When using the service, remember to restart it after making any changes to projects or triggers; otherwise, the server will not recognize the updates.
❗
Note that after each system update, the service is reinstalled and will operate in the same startup mode it was configured to use prior to the update.

By default, the service is installed to log on as the Local System Account, which may cause permission issues when connecting to data sources such as network drives, ODBC connections, or databases requiring domain authentication.

In such cases, you should change the service logon method in the Log On tab within the service properties and specify a user account that has the necessary permissions.

image
icon

Remember to change the account again after a system update. The GRAVITY system does not retrieve or store local user accounts.

Server as an Application (GravityTriggerRunner)

Designed for use in a development environment. Thanks to its graphical interface, verifying project execution, restarting processes, and loading new triggers or projects is much simpler. Unlike the service, it does not require restarting the entire application — only the selected trigger needs to be restarted.

After installing the GRAVITY system, you can find the server application as GravityTriggersRunner.exe. It has to be run with administrator privileges.

The GravityTriggerRunner application contains two tabs — Log and Triggers control.

Log Tab

The Log tab displays information about events occurring within the server application. It records the server startup, each invocation, individual steps, and the results of trigger execution. The log is simultaneously written to log files located in C:\ProgramData\Caffeine Minds\Gravity\ServiceLogs. Within the application, the last 1,000 log entries are retained and can be cleared manually using the Clear button.

image

Triggers Control Tab

The tab displays a list of defined triggers that have the Enabled switch selected in their configuration. Triggers are grouped into folders that can be expanded or collapsed with a mouse click. The list provides basic information about each trigger, including its current status, the time of the last execution, the number of successful and failed invocations, and the option for managing the trigger’s state.

image

After the application is started and the triggers and projects are loaded, the system sets the triggers to Run status, provided that no errors occurred in the definition of the project linked to the trigger.

A trigger can have the following statuses:

  • Run → enabled and waiting for invocation
  • Processing → currently invoking a process
  • Stop → stopped; trigger invocation is not possible
  • Restarting → currently restarting

Each trigger provides a set of options that allow you to manage its state:

image

Option 1 – Re-enable – restarts the trigger; if the process definition has changed, it will not be reloaded automatically. Option 2 – Disable – stops the trigger from running. Option 3 – Reload – use this option when the process definition has changed; other triggers will continue operating without interruption.

Option 4 – View Log – allows you to check the trigger’s execution history and diagnose any potential errors.

image

Double-clicking a log entry allows you to view execution details.

Above the list, there are buttons that perform global actions for the entire list:

image
  • Refresh list → refreshes the list data; does not reload new data after modifications to projects or triggers.
  • Restart All → restarts all triggers displayed in the list, reloading their configurations along with the corresponding project configurations.
  • Update Triggers → checks whether any triggers have been added or removed and updates them in the system (this does not restart existing triggers; it only loads new ones and removes those that no longer exist).
icon
To better understand and prepare for working with triggers, refer also to the GRAVITY Process InvocationGRAVITY Process Invocation section.