Purpose
This guide explains how to configure the GLPI Response integration in Logsign USO, so that Incidents and Alarms can automatically, or an analyst can manually, create a GLPI ticket and look up ticket details directly from a Logsign Incident. This is a Response (action) integration, configured under Settings > Integrations > Responses > +Device. Once a device is configured, GLPI can also be selected in the Action Rules wizard so that a ticket is opened without analyst interaction.
Prerequisites
- A GLPI instance with its REST API (apirest.php) enabled and reachable from the Logsign server.
- A GLPI account with permission to create and view tickets, plus an App Token for the REST API.
- If you plan to open tickets in a specific GLPI entity, the same account must be allowed to create tickets in every entity you target. GLPI rejects a ticket for an entity the account cannot write to, and the Logsign action fails.
- Use least privilege. Create a dedicated GLPI account for this integration scoped to ticket creation/viewing rather than a full administrator profile.
Step 1: Prepare GLPI for API Access
- Log in to GLPI as an administrator and enable the REST API (Setup > General > API), if not already enabled.
- Create an App Token for the API client that will be used (Setup > API, add a new API client, enable it, generate an App Token).
- Create (or designate) a dedicated GLPI user account for Logsign to use, and generate a personal User Token for it from that user's Preferences (My Settings) page.
- Note the numeric ID of every GLPI entity you want tickets to land in (Administration > Entities, the ID is shown in the entity's URL). You will enter this ID in the action, not the entity name.
Step 2: Configure the Integration in Logsign USO
In Logsign USO, go to Settings > Integrations > Responses, search for GLPI, click Configure then +Device, and fill in:
| Field | Required | Description |
|---|---|---|
| Device Name | Yes | Free-text label identifying this GLPI device in Logsign. |
| Url | Yes | Base URL of your GLPI REST API (defaults to http://127.0.0.1/apirest.php in the form; change it to your actual GLPI instance's apirest.php address). |
| User Token | Yes | The personal User Token from Step 1. Stored encrypted at rest. |
| App Token | Yes | The App Token from Step 1. Stored encrypted at rest. |
| Insecure Skip Verify | Yes | Disables TLS certificate validation on Logsign's outbound calls when enabled. Defaults to on; leave off unless you have a specific reason to keep it enabled. |
Click Create to save the device.
Available Methods
create_ticket (Containment)
Creates a GLPI ticket. The arguments are:
| Argument | Required | Description |
|---|---|---|
| Name | Yes | Ticket title. Supports incident field references (see below) and is pre-filled with a default template. |
| Description | Yes | Ticket content. Supports incident field references and is pre-filled with a multi-line default template covering incident ID and URL, alert info, category, severity, source and destination IP, event source and generation time. |
| Category | Yes | Numeric GLPI ITIL category ID, not the display name. Look it up under Setup > Dropdowns > ITIL Categories. Submitting a name instead of an ID fails. |
| Ticket Type | Yes | Numeric GLPI ticket type ID, typically 1 for Incident and 2 for Request. Submitting a name instead of an ID fails. |
| Entity ID | No | Numeric GLPI entity ID the ticket is created in. Leave it empty, or let it resolve to an empty value, and the ticket goes to the root entity as before. A non-numeric value fails the action. |
| Priority | No | Ticket priority. Accepts Low, Medium, High, Urgent (case-insensitive) or a number from 1 to 6. Defaults to the incident priority through $GET['Priority.Name']. Leave it empty or enter a value outside this set and Logsign sends no priority, so GLPI applies its own default (Medium). |
Low, Medium, High and Urgent are sent to GLPI as urgency and impact 2, 3, 4 and 5 respectively, with the same number as the ticket priority. A numeric value is sent as the ticket priority directly, while urgency and impact are capped at 5, so a Priority of 6 produces urgency 5, impact 5 and priority 6 (Major) in GLPI.
Tickets are no longer checked for a duplicate title before creation. Creating a second ticket with a name that already exists in GLPI succeeds and produces a separate ticket, which is what you want when the same alarm fires for several customers or entities.
get_ticket (Analysis)
Fetches ticket detail and returns a large set of fields including status, priority, SLA and dates. It takes two arguments, and at least one of them must be filled in:
| Argument | Required | Description |
|---|---|---|
| Ticket ID | No | Numeric GLPI ticket ID. When it is filled in, the ticket is read directly and the Name argument is ignored. |
| Name | No | Ticket title. Logsign searches GLPI for a ticket with this title and returns the first match. Use the Ticket ID when titles can repeat. |
Leave both empty and the action fails with "ticket id or name is required".
Referencing Incident Fields
The Name, Description, Entity ID and Priority fields of create_ticket accept incident field references, and typing $ in the field opens the field picker. The accepted syntax is the full reference, for example $GET['TriggeredAlert.Source.IP'] or $GET['Priority.Name']. A short form such as $Source.IP is not resolved and is sent to GLPI as literal text.
Name and Description already come with default templates, so an action works without editing them. Keep in mind that a reference resolving to an empty value in Entity ID means no entity is sent and the ticket is created in the root entity.
Automatic Ticket Creation with Action Rules
GLPI is available in the Action Rules wizard, so create_ticket can run without an analyst. Build the rule as described in Understanding of Fully Automatic Response Technology with Action Rule, select the GLPI device and the create_ticket action, and fill in the same arguments as above. The rule runs when a new incident is opened or when a different alarm is added to an open incident. The same alarm arriving again on an open incident does not create a second ticket.
get_ticket is a read method and is intentionally not offered in the Action Rules wizard. Use it from an incident, manually or from a playbook.
Troubleshooting
| Symptom | Likely cause | What to check |
|---|---|---|
| 400/401 error mentioning the App Token | The API client in GLPI's Setup > API is disabled, or the App Token is wrong. | Confirm the API client is enabled in GLPI and the App Token matches. |
| 401 Unauthorized with the correct App Token | Wrong or expired User Token. | Re-generate the User Token from the GLPI account's Preferences page and update Logsign. |
| 403 Forbidden on create_ticket | The GLPI account does not have permission to create tickets in the target category. | Confirm the account's profile/entity rights in GLPI include ticket creation. |
| create_ticket fails with a parse/invalid-value error on category or ticket_type | A category or ticket type name was entered instead of its numeric GLPI ID. | Look up the numeric ID in GLPI (Setup > Dropdowns > ITIL Categories for category; 1=Incident/2=Request for ticket_type) and pass that instead. |
| create_ticket fails with a 400 response and ERROR_GLPI_ADD | The Entity ID does not exist, or the GLPI account is not allowed to create tickets in it. | Check the entity ID under Administration > Entities and give the API account ticket creation rights in that entity. |
| Action fails with "invalid entity id" or "invalid ticket id" | A non-numeric value reached Entity ID or Ticket ID, often an unresolved field reference. | Use the numeric ID, or a field reference that resolves to one. An empty Entity ID is allowed and sends the ticket to the root entity. |
| get_ticket fails with ERROR_ITEM_NOT_FOUND | No ticket matches the given ID, or no ticket carries the given title. | Verify the ticket ID in GLPI, or query by title only when the title is unique. |
A GLPI error response is reported as a failed action together with the message returned by GLPI, so an action shown as successful means GLPI accepted the request.
Notes and Limits
- GLPI's REST API requires two separate tokens (App Token for the API client, User Token for the account) that are easy to confuse; keep track of which is which when troubleshooting authentication errors.
- Priority is written to GLPI at creation time. Changing the priority of the Logsign incident afterwards does not update the GLPI ticket.
- The integration is one-way. Closing or updating a ticket in GLPI does not change the related Logsign incident, and there is no ticket synchronization back into Logsign.