Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 60 Next »

TIXnGO is the leading secure mobile wallet solution provided by the SecuTix company.

Please refer to this page for the functionalities of the product.

To set up product that can use this interface, please refer this page 

The document describes the features and the setup steps of the interface between SecuTix 360 and TIXnGO

Data streams

Ticket Injection: External printing. When executing this function, the ticket will pass to "printed" status on Secutix, and it will be injected on TIXnGO

Cancelled ticket: Push that has been cancelled in Secutix into TIXnGO. So the new status of the processed ticket will be cancelled on TIXnGO

Controlled ticket: 

Global setup of the interface

As for SecuTix 360, the TixNGo system is perceived as an external printing system. Tickets injected into TIXnGO are considered as printed.

In case of multi organization, the organization must be set up in the organization owing the inventory of the tickets (the organization where the catalog is defined)

To set it up:

1.) In Organization/Tools/Interfaces create a new External Printing Interface of type "TIXnGO" or "TixnGO with ticket template" (If you want to use the Ticket Template Editor to custom the data send to TIXNGO /wiki/spaces/CF/pages/40576543)

2.) Fill in the API URL provided by TIXnGO in the URL field. It must end by organizer/tickets

3.) Fill in the username provided by TIXnGO (I guess the value does not matter)

4.) In the password field, fill in the API key provided by TIXnGO

5.) Inject some test tickets.

The field "Email notification...." allows you to receive emails when one of the asynchronous processes described below is failing.

Should we set up different interfaces for given organization to speed the things up?

No. Else the push cancelled tickets and push will not work.

Don't.


Push cancelled and invalidated tickets

This batch pushes the cancelled and invalidated tickets to TIXnGO.

The tickets pushed are all the ones that:

  1. Have been injected
  2. Have been cancelled/invalidated
  3. Comply with the filter (shipment mode)
  4. Have not been already pushed by that function for that given interface


Recommended frequency

Every 5 minutes.

Date from

Can be used to force the sending of all cancelled tickets as if the last successful execution of the function was at the given date..

Do not use it if you don't understand clearly the usage, it may trigger thousands of unwanted notifications on remote cell phones.

Batch size

Recommended value: 1000

Ticket visibility rule

S-360 is pushing cancelled and invalidated tickets using an TIXnGI Api parameter called showDeletedTicket which defines its visibility.

The visibility for deleted tickets is following the rules:

  1. if the cancellation cause is in the list of overrideVisibilityFlagForInvalidationReasons (default value: empty), the the visibility is true. (showDeletedTicket =true)
  2. Else, if the checkbox "Notify spectator" is checked, the the visibility is set to true. (showDeletedTicket =true)
  3. Else default visbility is used. Default: false (showDeletedTicket =false), Can be altered using custom parameter: visibilityFlagDefaultValue. 

Push controlled tickets

This batch pushes the controlled status of the tickets to TIXnGO

The tickets pushed are all the ones that:

  1. Have been injected
  2. Have been controlled
  3. Comply with the filter (shipment mode)
  4. Have not been already pushed by that function for that given interface

Recommended frequency

Every 5 minutes. Can run every minute during event.

Date from

Can be used to force the sending of all controlled tickets as if the last successful execution of the function was at the given date..

Do not use it if you don't understand clearly the usage.

Batch size

Recommended value: 1000

Retrieve ticket status from TIXnGO

This function retrieves information from TIXnGO about the ticket holder and stores it inside SecuTix.

Only the batch size not already handled tickets are retrieved from TIXnGO.

Only one function "retrieve ticket status from TIXnGO" must run for a given organizer, regardless if tickets are injected from multiple 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

Custom parameters

Custom parametersPurpose 
ticketIterationSize

This custom parameter is used for the Tickets external printing/ Push cancelled and validate tickets/ Push controlled tickets. To support larger batch sizes, split them into smaller calls to blockchain to send smaller batches, one after the other inside the same execution. The default split size is 50

Note: The TIXnGO side supported only 50 tickets/times, so that should be kept as default.

batchSplitSize

This custom parameter is used for the Retrieve tickets status from TIXnGO batch. To support larger batch sizes, split them into smaller calls to blockchain to retrieve smaller batches, one after the other inside the same execution. The default split size is 1000

Example: Batch size in the Retrieve tickets status from TIXnGO = 5000, batchSplitSize = 1000. It will split 5000 to 5 calls in the same execution with 1000 per call

resetInjectionInvalidationReasons

This custom parameter is used for the Tickets external printing to allow injecting mobile tickets to the latest ticket holder contact or cultural contact based on the invalidation reason, i.e., reseating

Example: After injecting ticket into TnG for contact A (cultural contact) then contact A open mobile app and transfer the ticket to contact B (latest mobile owner). On the STX side, the operator reprinted that ticket with invalidation reason THEFT and reinject it into TnG, this ticket will reinject back to contact A. If there is no invalidation reason here, the new ticket will be reinjected back to contact B

Note: All the cancellation reasons are those which appear on the list of values in the BO [Institution > Initialisation > List of values > Ticket (Cancellation cause)]. With validation reason Theft , rESEATING will work too because the invalidation causes will be modified in order to remove the spaces and to be all set in upper cases

excludeTicketResale
overrideVisibilityFlagForInvalidationReasons

Both custom parameters are used for putting blockchain tickets into the resale platform and specified for Push cancelled and validate ticket batch. The purpose of those parameters is to update the invalidation reason to TnG after putting the ticket on the resale platform or tickets is resold.

Example: excludeTicketResale=true, overrideVisibilityFlagForInvalidationReason=RESALE_PENDING, RESOLD

After putting the ticket on the resale platform, the old ticket is invalidated and the validation reason will be updated into TnG side by the Push cancelled and validate ticket with invalidation set at overrideVisibilityFlagForInvalidationReason

For more information, please refer to the US STX-110559

dumpTnPRvariables=trueTo generate tnPRVariables file ticket detail after injecting ticket into TnG. To check the variable and its value as well
enforceMandatoryParametersThe interface fails with a proper error message before calling TixNGo if the mandatory parameters of the tickets to inject are not present.
Default value : true. Do not change if you don't know what you are doing.
dumpDataModifiedByTemplateDefault value: false. Set it to true to log the values modified by the template associated to the export.
overlaySpectatirDetailsWithLastOwner

Default value: true. Set it to false to skip the rule: But, IF the tickets has been reprinted, it will be assigned to its last known holder, as retrieved from TIXnGO.
(warning) The parameter is spelled with "Spectatir" (typo included) not "Spectator" as you may expect.

TIXNGO_LIFECYCLE_MODE

Only possible value lifecycle. When enabled, activates ticket status feature related to STX-122715 - Getting issue details... STATUS
If not used, the default mode for synchronisation is the history/legacy one. For more info about lifecycle vs history, please refer to this page : Retrieve ticket status from TIXnGO

sendmultilingualjsonobject=true

To inject tickets to TIXNGO  from S360 or by CSV with multilingual support STX-127552 - Getting issue details... STATUS

usePushCancelledTicketsV1

Default value: false. Set it to true to use the deprecated query to get the list of cancelled/invalidated tickets.
(warning) DEPRECATED. Either set it explicitly to false or remove completely the custom parameter.

doPatchWhenPushingControlledTicketsBy default is set to use PATCH in the API call. If set to false (doPatchWhenPushingControlledTickets=false), the method POST will be used.









  • No labels