Page tree

Supported parameters (07.02.2024)

Custom parametersPurpose 
Interface Global Parameters
killRatioThis parameter is technical,  for advanced configuration. To avoid blocking the execution of the interface
doContinueInCaseOfSyncError doContinueInCaseOfSyncError=true  required for “Receive ticket status from TIXnGO” interface functionality, prevents same error tickets being considered by the interface multiple times.
stickToTheHour

Advanced configuration. Default value: true
When true, schedule is executed every 5', sticking to the minutes ending by 5. If it executes at 13h35 and has a duration of 7 minutes, next execution won't be 13h42 (35+7), but 45 (35+7, rounding to the next x5 minutes)
When false, schedule is executed every 5',If it executes at 13h35 and has a duration of 7 minutes, execution will be at 13h42 (35+7).

maxLengthDumpedCallsInKbs

Advanced configuration. Use for troubleshooting ONLY. In order to save the payloads exchanged between S-360 & TIXNGO, you can use maxLengthDumpedCallsInKbs=5000

Ticket Injection
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.
overlaySpectatorDetailsWithLastOwner

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

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

resetInjectionInvalidationReasons=ITA_WRONG_DATA  this is required for ticket reprint functionality. With this setup if mobile ticket is reprinted with invalidation reason “WRONG DATA” ticket will be injected to the current cultural contact and not to the latest owner.

sendMultilingualAsJsonObject

updateJSONInsteadOfObject

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

(question) What it is exactly doing ? The code mentions "Control the missing mappings addition".

allowDefaultMobileAppId(question)
Retrieve ticket status
TIXNGO_LIFECYCLE_MODE

Only possible value lifecycle. By default; TIXNGO_LIFECYCLE_MODE=lifecycle For more info about lifecycle vs history, please refer to this page : 4. Retrieve ticket status from TIXnGO

additionalDiffParameters

Multi-value parameters allowing to customize results returned by TIXNGO diff end-point when the lifecycle mode is enabled "TIXNGO_LIFECYCLE_MODE=lifecycle").
With additionalDiffParameters=lightPayload=true you'll get rid of the legacy status and history object by applying the following customer parameter. this is set by default.

Use additionalDiffParameters=lightPayload=true&updatedDate=<date-time> to filter tickets by date,  example additionalDiffParameters=lightPayload=true&updatedDate=2022-08-15T04:25:28.483Z 

Use additionalDiffParameters=lightPayload=true&taxNumber=<list of tax number> to filter tickets by taxNumber, example additionalDiffParameters=lightPayload=true&updatedDate=2023-05-01T04:25:28.483Z&taxNumber=01010043155

For more information please refer to the US TIX2-3167

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

enableTicketDistributionToCulturalContact

Default value: false

When true, for a sucessfully transferred ticket, will create a cultural contact and change the CC of this ticket by this newly created contact (ie "Distribute the ticket") while introducing a new row into the Distribution history. For other "PENDING" statuses, will create a contact based on what is already returned by TIXNGO and update it later when the transfer is either completed or cancelled/interrupted.
When false, no contact creation, no ticket distribution.

Push Cancelled
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.

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. by default.

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.

For more information regarding visibility rule, please refer to the section "Ticket visibility rule" in https://confluence.secutix.com/x/tAxWCg

Push Controlled
doPatchWhenPushingControlledTicketsBy default is set to use PATCH in the API call. If set to false (doPatchWhenPushingControlledTickets=false), the method POST will be used.
controlledTicketsBucketSizeInteger. Number of tickets pushed to TNG in one run.
  • No labels

1 Comment

  1. aws

    LKL Could you please provide an explanation about the following:

    • controlledTicketsBucketSize=x - i do not see it on the list above - could you please explain ?
    • excludeTicketResale: is the right naming since by example RBL is using "excludeResaleTickets=true"

    Thanks for your feedback