Try Now

Requirements and Technology

Report/Audit DB Connector

You are always compliant and auditable

Long-term storage

Each action executed generates a report. The data is first stored in the intrasystem circulation database and can be viewed completely with the Admin Web App.
Use the filter functions in the dashboard to quickly find the right entry. All data can be stored in parallel in an external database for long-term storage. You can use an existing SQL server for this.


Governance and compliance readiness increasingly require the complete traceability of all processes. The use of PowerShell scripts is also not excluded. With the external database you can prove which scripts were executed on which system with which parameters, what the results were, etc. over the required periods of time. No matter if you use one or more ScriptRunner hosts.

Connection to SQL server with fault tolerance

ScriptRunner Report/Audit DB Connector connects the ScriptRunner host to the database on a Microsoft SQL server. If you run multiple ScriptRunner hosts, you can write them all to the same database. This means that you have all reporting information across all systems in a single database.

If a report was generated by an action, it is first written to the circulation database on the ScriptRunner host. Connector also generates an XML file whose contents are automatically transferred to the database on the SQL server. A restart after errors ensures that no report is lost and all data that has occurred in the meantime is stored in the database.


All important information stored

All information from the action reports in the circulation database on the host is also stored in the external database via the interface.

A section with meta-information reflects the processing and rights context. In particular which action was started when, by whom and via which interface the action was started and with which administrative account the script was executed on which target system.

The following information block shows the parameter values with which the script was started.

A short summary of the results is stored in the Result Message section. This summary is freely definable in the script and can be assigned via a PowerShell system variable.

If terminating errors occur, an error message is stored at the position of the result message. If errors do not terminate, corresponding error messages are also written.

Finally, the classic PowerShell output is displayed. You can add write-host output to each of your important processing steps in the script, which will then also be stored in the database.