...
...
...
| Table of Contents |
|---|
How does it work?
The "Retrieve ticket status from TIXnGO", also known as "Feedback interface" retrieves information from TIXnGO about the ticket holder and stores it inside S-360.
Only the batch size not already handled tickets are retrieved from TIXnGO.
...
Objectives
Synchronize TIXNGO tickets with S-360 Controlled tickets by retrieving the latest tickets updates from TIXNGO and storing TIXNGO-specific information, such as Mobile Ticket Status, Ticket Ownership and Ticket Beneficiaries (ie Assignee) into S-360.
Nominal behavior of the function
| Warning |
|---|
"Retrieve ticket status from TIXNGO" function does not support simultaneous executions. In other words, at any time, ONLY ONE function must be Active, regardless if tickets are injected, cancelled or controlled from multiple S-360 organizations. |
Recommended frequency
Every 5 minutes.
Pagination key
Do not touch this value if you do not know what you are doing.
Skip ticket
A non-mandatory parameter in which you can add all the ticket IDs that you want to skip.
Batch size
Recommended value: 1000
TIXNGO Ticket Status
In TIXNGO, we support 18 different statuses to ensure that at any time (before, during, and after an event), an organizer is able to know where a ticket is and who is its owner.
| Info | ||
|---|---|---|
| ||
INJECTED, DOWNLOADED, ASSIGNED, CONTROLLED, PENDING_TRANSFER, FAILURE_TRANSFER, TRANSFERRED, BT_ACTIVATED, MANUAL_ACTIVATED, OFFLINE_ACTIVATED, ONLINE_ACTIVATED, DELETION_PENDING, DELETED, ACTIVATED, DEACTIVATED, DEFAULT, INVALID, PENDING, FAILURE |
We can regroup these 18 statuses into 5 families :
- Initial delivery: the ticket is inserted into TIXNGO and/or into the spectator's wallet.
- Transfer: the ticket is moving from one wallet to another.
- Activation: the ticket is activated by one of the supported methods allowing the display of the QR code in the app.
- Control: the ticket has been used to enter event's premises.
- Deletion: the ticket has been deleted and cannot be used by a spectator.
...
TIXNGO Ticket Status
...
Printed
...
(after transfer cancelled by sender) FAILURE_TRANSFER
(after transfer rejected by receiver) FAILURE_TRANSFER
...
(after ticket activation) XXX_ACTIVATED (OFFLINE_ACTIVATED, ONLINE_ACTIVATED, MANUAL_ACTIVATED, BT_ACTIVATED)
...
Controlled
→ ACS control
→ Ticket check (BO)
...
(after control before feedback from TIXNGO) XYZ_ACTIVATED where XYZ is the activation method used
(after control and feedback from TIXNGO) CONTROLLED
...
Invalidated
→ Reprint ticket
→ Post ticket on resale
...
If the ticket was already existing in TIXNGO ...
- DELETION_PENDING (after sending the "invalidated status to TIXNGO and receiving feedback from TIXNGO)
- DELETED (after successful blockchain deletion and feedback from TIXNGO)
If the ticket was never sent to TIXNGO → NA
...
Cancelled
→ Cancel ticket (manually or by batch)
...
If the ticket was already existing in TIXNGO ...
- DELETION_PENDING (after sending the "cancelled/invalidated" status to TIXNGO and receiving feedback from TIXNGO)
- DELETED (after successful blockchain deletion and feedback from TIXNGO)
If the ticket was never sent to TIXNGO → NA
What and how we synchronize ticket details ?
Each mode has a specific mapping.
...
Work in progress → Final version will be uploaded when developement will be completed.
- BeaconName & ExtraInfoX
Jira Legacy showSummary false server SecuTix JIRA Tracking System serverId db7e2039-f715-3f84-b1ed-ba058a819c06 key STX-129962 - Cultural Contact creation
Jira Legacy showSummary false server SecuTix JIRA Tracking System serverId db7e2039-f715-3f84-b1ed-ba058a819c06 key STX-130794
...
07 Feb 2023
...
S360-TNG_Mapping_20230207.xlsx
...
Fixing nationality
| Jira Legacy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...
S360-TNG_Mapping_20221007.xlsx
...
How to configure the interface ?
In the custom parameters, to enable the lifecycle mode, you can use TIXNGO_LIFECYCLE_MODE=lifecycle.
By default, if not specified, the history mode will be used.
DEPRECATED
With the history mode (legacy behaviour), we synchronize the tickets from a "blockchain transaction" perspective
History mode (legacy behaviour)
- Possible Statuses (tixngo.legacyStatus) : INJECTED, RECEIVED, ACTIVATED, TRANSFER_PENDING, TRANSFERRED, CONTROLLED, DELETION_PENDING, DELETED
- Possible Actions : INJECT, TRANSFER, DELETE, BURN
- Possible States : PENDING, CONFIRMED, KO, DELETION_PENDING, DELETED, REGISTRATION_PENDING, CANCELLED, FAILED
...
S360 Blockchain Status (history)
...
Printed
...
(after injection) INJECTED
No Action/Status as long as the user does not have a wallet
...
(after download) RECEIVED
Action/Status : Inject/Confirmed
...
(after assignment) RECEIVED 
Holder/Assignee fields are set
Action/Status : Inject/Confirmed
...
(after transfer initiated) TRANSFER_PENDING
Action/Status : Inject/Confirmed
...
(after transfer cancelled by sender) RECEIVED ... or ... (after transfer rejected by receiver) RECEIVED
Action/Status : Inject/Confirmed
...
(after ticket activation) ACTIVATED
No specific Action/Status
...
Controlled
→ ACS control
→ Ticket check (BO)
...
(after control BUT before feedback from TIXNGO) ACTIVATED
(after control and feedback from TIXNGO) CONTROLLED
No specific Action/Status
...
Invalidated
→ Reprint ticket
→ Post ticket on resale
...
If the ticket was already existing in TIXNGO ...
- DELETION_PENDING (after sending the "cancelled/invalidated" status to TIXNGO and receiving feedback from TIXNGO)
- DELETED (after successful blockchain deletion and feedback from TIXNGO)
If the ticket was never sent to TIXNGO → NA
...
Cancelled
→ Cancel ticket (manually or by batch)
If the ticket was already existing in TIXNGO ...
- DELETION_PENDING (after sending the "cancelled/invalidated" status to TIXNGO and receiving feedback from TIXNGO)
- DELETED (after successful blockchain deletion and feedback from TIXNGO)
...
How does the function collect & process TIXNGO tickets?
The function will only process tickets that are returned by TIXNGO diff endpoint.
How does the function synchronize TIXNGO tickets into S-360?
Since the lifecycle introduction and the additional adjustments, the mapping is fixed and predictable, meaning that S-360 receives only what is necessary for its functioning and what is visible in the back-office screens.
| Info |
|---|
For more details about the exact mapping used, please refer to S-360 to TIXNGO interface > 4.1 Which TIXNGO ticket data is synced back to S-360 ? |
Since the "Contact Creation & Distribution" introduction, on top of the standard Ticket details refresh mechanism, it's possible to transform TIXNGO ticket ownership into S-360 cultural contact assignment.
| Info |
|---|
For more details about the criteria around Contact Creation & Cultural Contact Assignment, please refer to S-360 to TIXNGO interface > 4.2 Cultural Contact Creation & Distribution |
How to create the "Retrieve tickets" function?
If the TIXNGO interface has not been created or configured, please refer to S-360 to TIXNGO interface > 0. Initial setup of the interface
Once the basic configuration is completed, go the Schedules screen and click New button.
Select the function you want, in this case "Retrieve ticket status from TIXNGO" to add and Click Next.
How to configure the "Retrieve tickets" function?
| Field | Mandatory | Description | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Internal name | Yes | Name for this function | |||||||||
Launch | Yes | Either Manual or Automatic In case Automatic is selected, it's necessary to configure Frequency, Start, End | |||||||||
Frequency | Yes* | Mandatory only if Automatic schedule
| |||||||||
| Batch Size | Yes |
| |||||||||
Pagination Key | No | Self-sufficient parameter that is not meant to be overridden by an Operator
| |||||||||
| Skip Ticket Tax Numbers | No | List of Ticket Numbers aka Tax numbers (comma separated) that will be ignored if they're returned by TIXNGO | |||||||||
| File to upload | No | Will parse the attached file and process it as it was to TIXNGO
|
