...
This batch pushes the cancelled and invalidated tickets to TIXnGO.
It does not offer a lot of filtering possibilities.
The tickets extracted pushed are all the ones updated (that:
- Have been injected
- Have been cancelled/invalidated
...
- Comply with the filter (shipment mode)
- Have not been already pushed by that function for that given interface
Recommended frequency
Every 5 minutes.
Date from
This value allows to override the date of the last execution OK or Warning. If you keep it defined in a regular execution, the same tickets will be extracted and pushed over and over
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
What if tickets appears to be missing?
Create another schedule with a Date from defined before the cancellation and run it once.
Push controlled tickets
This batch pushes the controlled status of the tickets to TIXnGO
The tickets extracted pushed are all the ones updated (controlled) since the last execution ending OK or Warning.
Only tickets associated to a shipment mode with shipment mode type BLOCKCHAIN will be pushed.
...
that:
- Have been injected
- Have been controlled
- Comply with the filter (shipment mode)
- 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
This value allows overriding the date of the last execution OK or Warning. If you keep it defined in a regular execution, the same tickets will be extracted and pushed over and over.
Batch size
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: 1000Put a very high value (like 10'000)
Retrieve ticket status from TIXnGO
...
Batch size
Recommended value: 500For max speed outside operational periods, we recommend: batch size = 3000 (with batchSplitSize = 300)1000
Custom parameters
| Custom parameters | Purpose | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 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=true | To generate tnPRVariables file ticket detail after injecting ticket into TnG. To check the variable and its value as well | ||||||||||||
| enforceMandatoryParameters | The 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. | ||||||||||||
dumpDataModifiedByTemplate | Default 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. | ||||||||||||
| TIXNGO_LIFECYCLE_MODE | Only possible value lifecycle. Activates ticket status feature related to
| ||||||||||||
| sendmultilingualjsonobject=true | To inject tickets to TIXNGO from S360 or by CSV with multilingual support
|
...