Skip to content

Import UIP Configuration

Warning

Prior to importing any configuration files into an existing UIP, we recommend backing up the current configuration.

The Smart Guest Check-in Kiosk comes with configuration files that contain the configurations for the triggers, workflows and adapters needed in the UIP to support the various features available in the Kiosk Client. The supplied configuration files need to be imported into the Integration Platform for the necessary adapters to be used by the kiosk. Only the configuration files for the adapters being used by the site need to be imported. The installation requires one configuration file per category as listed in the table below. Some categories are optional depending on the features to be used such as email. Download the files needed below.

From the UIP management website, navigate to the Import Configuration menu option. Select the Browse button and search for the uip-<adapter_name>.json files located in the path from above. Make sure that when importing, you check the "Replace Existing" checkbox. Clicking the Import button will import the selected configuration into the UIP. This process needs to be repeated once for each of the listed categories.

Info

Checking the "Replace Existing" checkbox for each import will ensure that your UIP system has the latest versions of the necessary UIP objects (adapters, triggers and workflows). However, the "Replace Existing" option ends up in overwriting any prior configurations made for any existing adapters. Also, imports might have brought new adapters and triggers into your system. Therefore, when you're done with all the imports, remember to double-check each adapter's configuration and re-enter configuration settings if necessary. Also make sure that the necessary triggers are enabled.

Depending on your particular deployment scenario, you will need to import different UIP import files as seen in the table below. You must import one and only one file per each category. Duplicate categories will conflict if not disabled and also may consume needed license count for workflows and triggers.

Info

Adapters for supported systems not mentioned here can be used and imported in addition to or instead of the default adapters.

Category Adapter(s) Purpose JSON file(s) to import
PMS integration Oracle Opera PMS Interaction with the Opera PMS uip-opera-pms.json
PMS integration Infor HMS Interaction with the Infor HMS/PMS system uip-infor-pms.json
Face match NeoFace Watch Confirm identity based on face match uip-neoface-facematch.json
Face match SFA Confirm identity based on face match uip-sfa-facematch.json
Room Key Programming AssaAbloy + CRT-571 RFID Card Dispenser Hotel room keys programming uip-assaabloy-crt571-keycard.json
Room Key Programming AssaAbloy + CRT RFID Card Dispenser Hotel room keys programming uip-assaabloy-crt-keycard.json
Room Key Programming MIWA Hotel room keys programming uip-miwa-alv2-keycard.json
"Recognize Me" feature support Oracle Opera PMS + NeoFaceWatch Lookup guest reservations by means of their photo uip-opera-neoface-recognize-me.json
"Recognize Me" feature support Infor HMS + NeoFaceWatch Lookup guest reservations by means of their photo uip-infor-neoface-recognize-me.json
"Recognize Me" feature support Oracle Opera PMS + SFA Lookup guest reservations by means of their photo uip-opera-sfa-recognize-me.json
"Recognize Me" feature support Infor HMS + SFA Lookup guest reservations by means of their photo uip-infor-sfa-recognize-me.json
Payment/Financial support Opera PMS Import this file if your Kiosk environment is integrated with an Oracle Opera PMS with payment support via OPI. uip-opera-opi-creditcard.json
Payment/Financial support Infor HMS Import this file if your Kiosk environment is connecting to an Infor HMS hotel system, that is integrated with a payment provider to provide credit card payment support. uip-infor-opi-creditcard.json
QR code encoding QR Encoder Decoder Import this file to add support for generating QR codes that can be included in email notifications. uip-qrcode.json
QR code decoding - Support for parsing QR codes generated by a third party check-in system. uip-qrcode-parse.json
Messaging support Email Sender1 + HttpRequest1 Allow sending email and SMS notifications. uip-message-sender.json
External Document Validation (via STB/EVA) SFA + STB/EVA integration Support for integrating with the STB/EVA document validation system (using SFA for cropping person face) uip-sfa-eva-stb-integration.json
External Guest Data Source (James & Rita) Http Request Support for integrating with the James&Rita pre-check in system uip-james-and-rita.json
Request assistance Email Sender1 + HttpRequest1 Support for sending assistance request messages to hotel staff uip-assistance-call.json
Messaging support - Teams Microsoft Teams Supports sending Guest Check-In Confirmation notifications to a Teams channel. uip-teams-check-in-confirmation.json

1 These adapters are needed for certain functionality such as offering guest room check in info and invoice by text or email. Additional costs may apply for use of these services.

For more details on when to import a specific file, which objects (triggers, workflows) are imported and how to configure various adapters after import, please refer to the Overview of UIP Import files.

Changing comparison behavior for PMS name validations

When performing a CheckIn operation KIOSK sends request to compare provided first name/last name/full name at the scan with data provided earlier in the process from PMS. This comparison happens through a specific workflow in the respective PMS system (e.g. Opera - OperaOnValidation, Infor - InforOnValidation).

As per feature this comparison gives valid value(true) even if one word from first name/last name/full name are matched.

Example

Main guest checks In, after scan document system receives name as "Billy Wanka" if in the PMS he has been registered with name "Billy" or "Wanka", this would be sufficient to say that this person is legit. Because at least one word from combination is matching.

If it's required to do this match by 2 words from a combination of first name/last name/full name it can be done through workflow settings (OperaOnValidation, InforOnValidation - workflows): in the "Build regex for resvFullName" Set, in the Properties is a regex that performs the comparison. In this regex last digit shows minimum count of words that has to be match in order to return a positive value(names match): //

In this case a person has to have at least two matching words to be able to pass this check.

In the example above, with this setting, the check will not pass as this has only one word match.

Changing comparison behavior for PMS reservation lookup

When performing a search operation for reservation by number and last name, partial name match can be enabled. To achieve this effect, a new property was introduced (Opera and Infor adapters) to enable this behavior. The Boolean type Partial Comparison property will enable this behavior if set to "true", and in any other cases will be considered as disabled (searching by whole words only).

When enabled, allows to do a reservation lookup with a last name partial word that has minimum 3 characters length. Eg. to find a reservation that has last name "Lincoln" it is enough just "Lin" so search would return respective reservation.

//

This flag is the same flag that can be set in Kiosk Admin > System Settings. Modifying this value is Kiosk Admin is preferred. //

Increase Webhook Data Limits

The default value should be large enough to support data and images being sent across the system. Increasing the data limit is only needed if problems are encountered. In some cases the data sent across the system is larger than what can be accepted. If this is occurring, the document scanner step may return an error. To see if this is the issue, the log files for the Kiosk Client and the Integration Platform can be examined.

The Kiosk Client log file is located on the Kiosk Client machine in the folder "C:\ProgramData\NEC\kiosk\logs". To review the logs for the UIP open the Administration application for the Integration Platform and navigate to Administration > Logging Events.

If the Kiosk Client log file contains an error that say, "Request to scanner webhook failed, identity cannot be confirmed" and in the Integration Platform logs for the Source NEC Workflow Wait Webhook shows an error that says, "Nec.WFWaitWebhook.Controllers.WebhookController: Webhook content length is too large", then the size of data being sent and received is too large.

The max data size can be extended by increasing the accepted "webhook payload size". To do this, open a PuTTY session to the UIP machine and run the command below to set the accepted payload to 100MB.

docker service update --env-add NECWF_WEBHOOK_MAXSIZE=100000000 nap-wfe_wfwaitwebhook --force

It could happen that the data limit is still too small and scans will continue to fail even after the command has been run. In this case, you need to re-run the command with an increased amount (about 50 MB per attempt) for the NECWF_WEBHOOK_MAXSIZE variable. Rerun the command and test the scan step using an increased amount every time until the scan step no longer fails.

Increase Webhook Timeout

By default, the UIP webhooks are timing out after 1 minute. In case that some adapter commands need a time longer than 1 minute to complete, you need to configure the webhook timeout to a duration long enough to allow the command to complete execution without timing out. Otherwise the webhook will time out and this would cause failure indication in Kiosk Client, however the actual command may be actually succeeding.

For example, you may be needing a timeout longer than 1 minute for any operations related to credit cards.

The webhook timeout can be increased e.g. to 3 minutes by opening a PuTTY session to the UIP machine and running the command below.

docker service update --env-add NECWF_WEBHOOK_TIMEOUT=180 nap-wfe_wfwaitwebhook --force

It could happen that this timeout is still too small. In this case, you may need to re-run the command with an increased timeout (about 60 sec per attempt) until eventually you no longer see timeouts in Kiosk Client.

Overview of UIP Import Files

PMS integration support

The import files in this group provide support for integrating with various PMS systems.

uip-opera-pms.json

When to import

Import this file if your Kiosk environment needs to integrate with an Oracle Opera PMS (either cloud or on premise, with or without OPI integration)

Imported Adapters
  • OperaInHouse (type Opera PMS)
    • After import, this adapter needs to be configured with:
      • Opera Web Service URL:
      • User Name: User name to connect to the Opera Web Services
      • Password: Password to connect to the Opera Web Services
      • Domain: Domain to login to the Opera Web Services in secured mode
      • Secure Mode: Check if the Opera system is configured to authenticate requests in secure mode.
      • Opera Cloud Authentication: Check when connecting to Opera Cloud. It takes precedence over the Secure Mode setting.
      • Chain Code: The chain code used for Information Web Service interrogations
      • Resort Code: The resort code used for Information Web Service interrogations
      • Host Code: The host code used for Information Web Service interrogations
      • Default Guarantee Type for New Reservations: The default rate plan code that the adapter will use for creating new reservations. Default value is COMPANY.
      • Default Rate Plan Code for New Reservations: The default rate plan code that the adapter will use for creating new reservations. Default value is NR.
      • Default Address Type: The default address type that the adapter will use for creating profile addresses. Default value is HOME.
      • Use Country and Nationality 3 Letters Codes: Check this box when the PMS is using 3 letters ISO codes for country and nationality.
      • Default Language Code: Default language code set to the guest profile. If left empty 'E' code will be used.
      • Time Zone: The time zone of the PMS.
Imported Triggers
  • PMSCallOpera (webhook name PMSCall)
    • Calls the OperaWorkflow workflow to perform PMS operations such as Find Reservation, Check In, Check out, Get Folio etc.
  • ValidateOpera (webhook name Validate)
    • Calls the OperaOnValidation workflow to validate operations given the reservation data and current status
  • ClientErrorLog (webhook name clientErrorLog)
    • Calls the ClientErrorLog workflow to notify hotel staff about any operations that failed on Kiosk Client side
Imported Workflows
  • OperaWorkflow
    • Uses the OperaInHouse adapter to perform PMS operations such as Find Reservation, Check In, Check out, Get Folio etc.
  • OperaOnValidation
    • Validates operations given the reservation data and current status.
    • It does not need an adapter, however the data that is verified is specific to Opera PMS's so it is shipped as part of uip-opera-pms import file.
  • ClientErrorLog
    • Sends notification messages (as email or SMS) to the destination configured in the workflow. This destination can be either an email address or a phone number (in case when the assistance request is sent as SMS).
    • Messages are sent via the via the SendTextMessage workflow.
Dependencies

Import uip-message-sender.json to get the following objects:

  • Adapters: EmailSender (type Email Sender)

  • Adapters: HttpRequest (type Http Request)

  • Workflow: SendTextMessage

    • After import, this workflow must be configured with settings to send email or SMS messages through appropriate services

uip-infor-pms.json

When to import

Import this file if your Kiosk environment needs to integrate with a PMS of type Infor HMS.

Imported Adapters
  • InforInHouse (type Infor PMS)
    • After import, this adapter needs to be configured with:
      • Infor URI: URL of the Infor Web Service. Typically provided by the Infor solution vendor.
      • User Name: User name to connect to the Infor Web Service. Typically provided by the Infor solution vendor.
      • Password: Password to connect to the Infor Web Service. Typically provided by the Infor solution vendor.
      • Hotel Code:The hotel code used for Infor Web Service interrogations. Typically provided by the Infor solution vendor.
Imported Triggers
  • PMSCallInfor (webhook name PMSCall)
    • Calls the InforWorkflow workflow to perform PMS operations such as Find Reservation, Check In, Check out, Get Folio etc.
  • ValidateInfor (webhook name Validate)
    • Calls the InforOnValidation workflow to validate operations given the reservation data and current status
  • ClientErrorLog (webhook name clientErrorLog)
    • Calls the ClientErrorLog workflow to notify hotel staff about any operations that failed on Kiosk Client side
Imported Workflows
  • InforWorkflow
    • Uses the InforInHouse adapter to perform PMS operations such as Find Reservation, Check In, Check out, Get Folio etc.

  • InforOnValidation

    • Validates operations given the reservation data and current status.
    • It does not need an adapter, however the data that is verified is specific to Infor PMS's so it is shipped as part of uip-infor-pms import file.

  • ClientErrorLog

    • Sends notification messages (as email or SMS) to the destination configured in the workflow. This destination can be either an email address or a phone number (in case when the assistance request is sent as SMS).
    • Messages are sent via the via the SendTextMessage workflow.
Dependencies

Import uip-message-sender.json to get the following objects:

  • Adapters: EmailSender (type Email Sender)

  • Adapters: HttpRequest (type Http Request)

  • Workflow: SendTextMessage

    • After import, this workflow must be configured with settings to send email or SMS messages through appropriate services

Face match support

The import files in this group provide support for face match (that is, matching guests' live photos taken by Kiosk with photos from guests' ID documents, for confirming guests' identity).

uip-neoface-facematch.json

When to import

Import this file if your Kiosk environment needs to perform guest face match using a NeoFace system.

Imported Adapters
  • NeoFace (type NeoFace Watch)
Imported Triggers
  • NeoFaceFaceMatch (webhook name FaceMatch) which is called by the Kiosk Client to match guest photo with document photo
    • This trigger calls the NeoFaceMatchImages workflow (see below)
Imported Workflows
  • NeoFaceMatchImages
    • uses the NeoFace adapter to perform face match operations

uip-sfa-facematch.json

When to import

Import this file if your Kiosk environment needs to perform guest face match using a SFA (Kaoato) system.

Imported Adapters
  • SFA (type sfa)
    • After import, this adapter needs to be configured with:
      • SFA URI: The URI to the SFA API
      • User Name: User name to login to the SFA API
      • Password: Password to login to the SFA API
      • deviceId: Unique ID of the device performing actions on SFA API.
        • Not actually needed for face match. Enter anything not empty.
Imported Triggers
  • SfaFaceMatch (webhook name FaceMatch) which is called by the Kiosk Client to match guest photo with document photo
    • This trigger calls the SfaMatchImages workflow (see below)
Imported Workflows
  • SfaMatchImages
    • uses the SFA adapter to perform face match operations

'Recognize me' support

The import files in this group provide support for the 'Recognize me' feature (that is, matching guests' photos taken by Kiosk, with images inside a face match system such as NeoFace, as an alternative reservation lookup method).

uip-infor-neoface-recognize-me.json

When to import

Import this file if:

  • your Kiosk environment integrates with a PMS of type Infor HMS
  • face match support is provided by a NeoFace system
  • your Kiosk environment needs to provide the 'Recognize Me' feature
Imported Workflows
  • InforFindReservationUsingPhoto
    • Step 1: it identifies the person (subject) in the NeoFace system using the photo taken by Kiosk, by means of the Find Person command of the NeoFace adapter
    • Step 2: it identifies the reservation in the Infor system, by means of the Find Reservation command of the InforInHouse adapter, and using the person name and unique ID in the Infor system
Dependencies

Import uip-infor-pms.json to get the following objects:

  • Adapter: InforInHouse (type Infor HMS)

Import uip-neoface-facematch.json to get the following objects:

  • Adapter: NeoFace (type NeoFace Watch)

uip-opera-neoface-recognize-me.json

When to import

Import this file if:

  • your Kiosk environment integrates with an Oracle Opera PMS (cloud or on prem, with or without OPI integration)
  • face match support is provided by a NeoFace system
  • your Kiosk environment needs to provide the 'Recognize Me' feature
Imported Workflows
  • OperaFindReservationUsingPhoto
    • Step 1: it identifies the person (subject) in the NeoFace system using the photo taken by Kiosk, by means of the Find Person command of the NeoFace adapter
    • Step 2: it identifies the reservation in the Infor system, by means of the Find Reservation command of the OperaInHouse adapter, and using the person name and unique ID in the Infor system
Dependencies

Import uip-opera-pms.json to get the following objects:

  • Adapter: OperaInHouse (type Opera PMS)

Import uip-neoface-facematch.json to get the following objects:

  • Adapter: NeoFace (type NeoFace Watch)

uip-infor-sfa-recognize-me

When to import

Import this file if:

  • your Kiosk environment integrates with a PMS of type Infor HMS
  • face match support is provided by a SFA system
  • your Kiosk environment needs to provide the 'Recognize Me' feature
Imported Workflows
  • InforFindReservationUsingPhoto
    • Step 1: it identifies the person (subject) in the SFA system using the photo taken by Kiosk, by means of the matchFaceWithRegistrant command of the SFA adapter
    • Step 2: it identifies the reservation in the Infor system, by means of the Find Reservation command of the InforInHouse adapter, and using the person name and unique ID in the Infor system
Dependencies

Import uip-infor-pms.json to get the following objects:

  • Adapter: InforInHouse (type Infor HMS)

Import uip-sfa-facematch.json to get the following objects:

  • Adapter: SFA (type sfa)

uip-opera-sfa-recognize-me

When to import

Import this file if:

  • your Kiosk environment integrates with a PMS of type Oracle Opera PMS
  • face match support is provided by a SFA system
  • your Kiosk environment needs to provide the 'Recognize Me' feature
Imported Workflows
  • OperaFindReservationUsingPhoto
    • Step 1: it identifies the person (subject) in the SFA system using the photo taken by Kiosk, by means of the matchFaceWithRegistrant command of the SFA adapter
    • Step 2: it identifies the reservation in the Infor system, by means of the Find Reservation command of the OperaInHouse adapter, and using the person name and unique ID in the Infor system
Dependencies

Import uip-opera-pms.json to get the following objects:

  • Adapter: OperaInHouse (type Opera PMS)

Import uip-sfa-facematch.json to get the following objects:

  • Adapter: SFA (type sfa)

Payment/financial support

uip-opera-opi-creditcard.json

When to import

Import this file if your Kiosk environment is connecting to an Oracle Opera PMS hotel system, that has payment support via Oracle's OPI interface.

Imported Adapters

None - it depends on the OperaInHouse adapter.

Imported Triggers
  • OperaOPIFinancial (webhook name financial) which is called by the Kiosk Client when it needs to perform payments
    • This trigger calls the OperaOPIFinancial workflow (see below)
Imported Workflows
  • OperaOPIFinancial
    • Performs payment operations using Opera PMS + OPI
Dependencies

Import uip-opera-pms.json to get the following objects:

  • Adapters: OperaInHouse (type Opera PMS)

uip-infor-opi-creditcard

When to import

Import this file if your Kiosk environment is connecting to an Infor HMS hotel system, that is integrated with a payment provider to provide credit card payment support.

Imported Adapters

None - it depends on the InforInHouse adapter.

Imported Triggers
  • InforOPIFinancial (webhook name financial) which is called by the Kiosk Client when it needs to perform payments
    • This trigger calls the InforOPIFinancial workflow (see below)
Imported Workflows
  • InforOPIFinancial
    • Performs payment operations using Infor HMS, through the integrated payment provider.
Dependencies

Import uip-infor-pms.json to get the following objects:

  • Adapters: InforInHouse (type Infor HMS)

Key programming support

uip-assaabloy-crt571-keycard.json

When to import

Import this file if your Kiosk environment needs to perform room key programming using an Assa Abloy (Visionline) system, and the room keys are dispensed/accepted by a CRT-571 dispenser machine.

Imported Adapters
  • AssaAbloy
    • After import, this adapter needs to be configured with:
      • AssaAbloy Service Type: The service type (visionline or vostio), default is visionline.
      • Assa Abloy Service Address (Web API or PMS Plus): The address of the Assa Abloy system to connect to
        • To connect via Visionline Web API, enter: https://<server_name_or_ip_address>/api/v1
        • To connect via PMS Plus, enter: <server_name_or_ip_address>:<port>.
        • To connect via Vostio Web API, enter https://vostio.api.assaabloy.com
      • User name (optional): the user name for an account with permissions to connect to the system. This is needed only when connecting via Web API.
      • Password (optional): the password for the user account with permissions to connect to the system. This is needed only when connecting via Web API.
      • User Pool Id: the user pool id (for vostio only)
      • Client Id: the client id (for vostio only)

  • dispenser_1

    • After import, this adapter needs to be configured with:
      • Controller service address: The fully qualified domain name (FQDN) or IP-Address for the CRT+571 device controller service.
      • Controller port: The port to connect to the CRT-571 device controller service.
      • CRT-571 Hardware Address (optional): The unit's hardware address. Must be set in range 0-15 according to the positions of the four dip switches on the physical device (Refer to CRT-571 manual) (Default=0)
      • CRT-571 Initialization Option (Optional): Sets state of the dispenser if a card is present while initializing. The card will be moved to the following possible positions. ("0"-Holding Position, "1"-Recycle Bin, "3"-Do Nothing) (Default=3)
      • Use TLS (optional): Check if the CRT-571 device controller service is using TLS
      • Service Secret Key (optional): The password for the CRT-571 device controller service.

    Warning

    Each Kiosk machine in the hotel needs to communicate with its own dispenser.

    • Therefore you need to create a dispenser adapter instance per each Kiosk machine.
    • Each Kiosk machine needs to be configured with the corresponding dispenser adapter name.
    • For consistency reasons we recommend that each dispenser adapter is named dispenser_X where X can be an unique identifier given to the adapter. For example, one can use a short string identifying the location of the dispenser, such as dispenser_building1_north.
Imported Triggers
  • AssaAbloyCRT571Keycard (webhook name keycard) which is called by the Kiosk Client when it needs to perform key programming related operations or to simply return a key card
    • This trigger calls the AssaAbloyCRT571Keycard workflow (see below)
Imported Workflows
  • AssaAbloyCRT571Keycard
    • Performs room key programming operations using the AssaAbloy adapter
    • Commands the dispenser to release/accept a room key card using the dispenser adapter with a specified name
    • Sends SMS notifications to a provided number in case that the dispenser is running low on key cards
Dependencies

Import uip-message-sender.json to get the following objects:

  • Adapters: EmailSender (type Email Sender)

  • Adapters: HttpRequest (type Http Request)

  • Workflow: SendTextMessage

    • After import, this workflow must be configured with settings to send SMS messages through appropriate services

uip-assaabloy-crt-keycard.json

When to import

Import this file if your Kiosk environment needs to perform room key programming using an Assa Abloy (Visionline) system, and the room keys are dispensed/accepted by a CRT dispenser machine.

Imported Adapters
  • Assaabloy
    • After import, this adapter needs to be configured with:
      • AssaAbloy Service Type: The service type (visionline or vostio), default is visionline.
      • Assa Abloy Service Address (Web API or PMS Plus): The address of the Assa Abloy system to connect to
        • To connect via Visionline Web API, enter: https://<server_name_or_ip_address>/api/v1
        • To connect via PMS Plus, enter: <server_name_or_ip_address>:<port>.
        • To connect via Vostio Web API, enter https://vostio.api.assaabloy.com
      • User name (optional): the user name for an account with permissions to connect to the system. This is needed only when connecting via Web API.
      • Password (optional): the password for the user account with permissions to connect to the system. This is needed only when connecting via Web API.
      • User Pool Id: the user pool id (for vostio only)
      • Client Id: the client id (for vostio only)

  • dispenser_1

    • After import, this adapter needs to be configured with:
      • Kiosk Server URL: The URL to connect to the Kiosk Server (e.g. https://server_name_or_ip_address:8080).
      • Kiosk Position: The name of the kiosk position the device is on.
      • Router Token: The token defined on the device side.
      • Client Certificate: The adapter client certificate (PEM format).
      • Client Private Key: The private key for the adapter client certificate (PEM format).
      • CRT Dispenser Model (optional): The dispenser model. m=CRT571-M y=CRT591-Y (Default: m)
      • CRT Hardware Address (optional): The unit's hardware address. Must be set in range 0-15 according to the positions of the four dip switches on the physical device (Refer to CRT manual) (Default=0)
      • CRT Initialization Option (Optional): Sets state of the dispenser if a card is present while initializing. The card will be moved to the following possible positions. ("0"-Holding Position, "1"-Recycle Bin, "3"-Do Nothing) (Default=3)

    Warning

    Each Kiosk machine in the hotel needs to communicate with its own dispenser.

    • Therefore you need to create a dispenser adapter instance per each Kiosk machine.
    • Each Kiosk machine needs to be configured with the corresponding dispenser adapter name.
    • For consistency reasons we recommend that each dispenser adapter is named dispenser_X where X can be an unique identifier given to the adapter. For example, one can use a short string identifying the location of the dispenser, such as dispenser_building1_north.
Imported Triggers
  • AssaAbloyCRTKeycard (webhook name keycard) which is called by the Kiosk Client when it needs to perform key programming related operations or to simply return a key card
    • This trigger calls the AssaAbloyCRTKeycard workflow (see below)
Imported Workflows
  • AssaAbloyCRTKeycard
    • Performs room key programming operations using the AssaAbloy adapter
    • Commands the dispenser to release/accept a room key card using the dispenser adapter with a specified name
    • Sends SMS notifications to a provided number in case that the dispenser is running low on key cards
    • The 'Dispenser Model' can be set in the Start step of the workflow, its default value is y which stands for CRT591-Y
Dependencies

Import uip-message-sender.json to get the following objects:

  • Adapters: EmailSender (type Email Sender)

  • Adapters: HttpRequest (type Http Request)

  • Workflow: SendTextMessage

    • After import, this workflow must be configured with settings to send SMS messages through appropriate services

uip-miwa-alv2-keycard.json

When to import

Import this file if your Kiosk environment needs to perform room key programming using a MIWA encoder + dispenser machine.

Please refer to Configuring Miwa Lock ALV3 and Adapter for detailed instructions on how to configure your Kiosk system to work with MIWA.

Dependencies

Import uip-message-sender.json to get the following objects:

  • Adapters: EmailSender (type Email Sender)

  • Adapters: HttpRequest (type Http Request)

  • Workflow: SendTextMessage

    • After import, this workflow must be configured with settings to send SMS messages through appropriate services

Messaging support

uip-message-sender.json

When to import

Import this file if your Kiosk environment needs to send:

  • email messages using the Email Sender adapter
  • SMS messages using the Http Request adapter
Imported Adapters
  • EmailSender (type Email Sender)
    • After import, this adapter needs to be configured with:
      • SMTP Server Address: The IP address or FQDN of the SMTP server e.g. smtp.gmail.com
      • SMTP Server Port: The port number to connect to the SMTP server, typically 465 for secure connections and 587 for insecure connections
      • Use secure connection to SMTP server (TLS): Check if the SMTP server is configured to use secure connections
      • From Address: From address for emails that are sent; if empty uses the username field as the 'From' address.
      • Username: Username required for authentication with SMTP server; this will also be used as the 'From' address when sending emails
      • Password: Password required for authentication with SMTP server
      • Maximum attachment size (MB): The maximum size of file in megabytes which can be sent as an attachment
  • HttpRequest (type Http Request)
    • After import, this adapter needs to be configured to communicate with a 3rd party SMS service (e.g. - Twilio) to send SMS messages via an HTTP API.
      • This may require adapter property settings (e.g. - specific headers) or modifications to the imported workflow described below.
Imported Triggers
  • SendTextMessage (webhook name SendTextMessage) which is called by the Kiosk Client when it needs to send email or SMS notifications
    • This trigger calls the SendTextMessage workflow (see below)
Imported Workflows
  • SendTextMessage
    • Sends email messages using the Email Sender adapter
    • Sends SMS messages using the Http Request adapter
      • The command configured for this purpose in the workflow is an HTTP Post, and must be configured or replaced with the appropriate request method to call a 3rd party API for handling SMS requests. The {destinationAddress} and {message} parameters passed to this workflow are to be used as the SMS request destination number and message, respectively.

uip-teams-check-in-confirmation.json

When to import

Import this file if your Kiosk environment:

  • has the 'Confirmation Requests' feature enabled
  • needs to send Teams channel messages using the Microsoft Teams adapter
Imported Adapters
  • teams (type Microsoft Teams)
Imported Triggers
  • Check-in Confirmation (webhook name confirmation) which is called when the Kiosk Client sends notifications for guest check-in confirmation
    • This trigger calls the Check-in Confirmation workflow (see below)
Imported Workflows
  • Check-in Confirmation
    • Sends Microsoft Teams channel messages using the Microsoft Teams adapter

CAUTION

  • The Incoming Webhook URL and Message need to be configured in the workflow, by editing its teams Send Message step.
  • The customers need to edit this workflow and adapt it to their particular necessities.

uip-qrcode.json

When to import

This file needs to be imported in all cases when your system needs to generate QR codes for speeding up the process of identifying the reservation. It is recommended that it is always imported.

Imported Adapters
  • QRCode (type QR Encoder Decoder)
    • This adapter does not need any configuration.
Imported Triggers
  • QRCodeEncode (webhook name qrCodeEncode) which is called by the Kiosk Client when it needs to encode a given data string into a QR code.
    • This trigger calls the QRCodeEncodeworkflow (see below)
Imported Workflows
  • QRCodeEncode
    • Encodes a given data string into a QR code.
Dependencies

None.

External Guest Data Source support

The import files in this group provide support for integrating with external guest data source systems such as James & Rita.

uip-james-and-rita.json

This import file provides support for integrating with the mobile check-in system known as James & Rita, which in this case will behave like an external guest data source for Kiosk.

When to import

Import this file if your Kiosk environment needs to integrate with the mobile check-in system known as James & Rita.

Imported Adapters
  • GenericHttp (type httprequest)
    • This adapter does not need any special configuration after the import, everything can be left at the default settings
Imported Triggers
  • JamesAndRitaTrigger (webhook name externalDataSource) which is called by the Kiosk Server for interacting with the J&R platform
    • This trigger calls the JamesAndRitaWorkflow workflow (see below)
Imported Workflows
  • JamesAndRitaWorkflow: Sends requests to fetch the guest reservation data (or to mark the reservation as checked-in, depending on the case) to the J&R platform through the GenericHttp adapter

External Document Validation support

The import files in this group provide support for integrating with external document validation systems such as STB/EVA.

uip-sfa-eva-stb-integration.json

This import file provides support for integrating with the STB/EVA document validation system (specific to Singapore).

  • STB stands for "Singapore Tourism Board"
    • It represents an organization which regulates, promotes and advertises the tourism activities which take place within Singapore
  • EVA stands for "E-Visitor Authentication"
    • It represents the STB's document validation platform.
    • STB requires that all ID documents of guests which are not Singapore residents need to be entered into / validated by this platform.
When to import

Import this file if your Kiosk environment needs to integrate with the STB/EVA platform.

Info

STB/EVA is a platform specific to Singapore. Typically, you will only need to import uip-sfa-eva-stb-integration.json if your Kiosk integrates with the PMS of a Singapore hotel.

Imported Adapters
  • SFA (typeSFA)
    • After import, this adapter needs to be configured with:
      • SFA URI: The URI to the SFA API
      • User Name: User name to login to the SFA API
      • Password: Password to login to the SFA API
      • deviceId: Unique ID of the device performing actions on SFA API.
        • Not actually needed for face match or detect face operations. Enter any non empty-value.
  • EVA (type EVA)
    • After import, this adapter needs to be configured with several settings which are typically provided by the Singapore Tourism Board following the registration process:
      • E-Visitor Check-in API URL: The URL for the Singapore Tourism Board API service and port. If the port is unspecified, the default will be assumed. https - 443, http - 8080.
      • E-Visitor Authentication API Key: The API Key necessary to access the Visitor API service.
      • Hotel ID: the hotel's license number as issued by the Hotel Licensing Board (HLB).
      • OAUTH Access Token API Host URL: The URL for the Singapore Tourism Board OAUTH service and port. If the port is unspecified, the default will be assumed. https - 443, http - 8080.
      • API Consumer Key: The ID provided by the Singapore Tourism Board following the registration process used to create authorization token.
      • API Consumer Secret: The Secret provided by the Singapore Tourism Board following the registration process used to create authorization token.
Imported Triggers
  • detectFace (webhook name detectFace) which is called by the Kiosk Server for cropping person's face from the full image of scanned ID document
    • This trigger calls the STB_SFA_DetectFace workflow (see below)
  • externalDocumentValidation (webhook name externalDocumentValidation) which is called by the Kiosk Server for validating an ID document using the STB/EVA platform
    • This trigger calls the STB_EVA_VisitorCheckIn workflow (see below)
Imported Workflows
  • STB_SFA_DetectFace: Calls the detectFace operation of SFA adapter to detect the coordinates of the rectangle that contains the person photo within the full image of scanned ID document. Based on these coordinates, Kiosk Server is able to crop the person photo and send it to STB EVA platform.
  • STB_EVA_VisitorCheckIn: Calls the visitorCheckIn operation of EVA adapter for sending guest data (as read from guest's scanned ID document) to STB EVA platform, to be registered and validated.

Generic purpose support

uip-assistance-call

When to import

This file is required so that the Kiosk system is able to send assistance request messages to hotel staff, either as email or as SMS.

Imported Triggers
  • CallAssistance (webhook name CallAssistance) which is called by the Kiosk Client when the guest is pressing the "Request Assistance" button (i.e. the question mark button)
    • This trigger calls the ParseQRCode workflow (see below)
Imported Workflows
  • SendAssistanceRequest
    • Sends an "Assistance Request" message (as email or SMS) to the destination configured in the workflow. This destination can be either an email address or a phone number (in case when the assistance request is sent as SMS).
    • Messages are sent via the via the SendTextMessage workflow.
Dependencies

Import uip-message-sender.json to get the following objects:

  • Adapters: EmailSender (type Email Sender)

  • Adapters: HttpRequest (type Http Request)

  • Workflow: SendTextMessage

    • After import, this workflow must be configured with settings to send email or SMS messages through appropriate services

uip-qrcode-parse

When to import

This file needs to be imported in all cases when your system needs to be able to read QR codes generated by a third party booking system.

Imported Adapters
  • None - it does not use any adapters
Imported Triggers
  • ParseQRCode (webhook name ParseQRCode) which is called by the Kiosk Client when it needs to parse a data string provided as QR code.
    • This trigger calls the ParseQRCode workflow (see below)
Imported Workflows

  • ParseQRCode

    • Parses a data string provided as a QR code, returning the reservation number and the guest last name to Kiosk.

    CAUTION

    • This workflow provided to the customer as a sample of how to parse a QR code generated based on a string formatted as <ResvStayID>&<ConfirmationNumber>&<GuestLastName>&<Channel>&<Language>.
    • The customers need to edit this workflow and adapt it to their particular necessities.

Best practices after the import

After you have finished importing the files necessary for your system, we recommend to always do the checks depicted in the following sections, as a set of best practices.

Check Triggers

Check the UIP's Triggers page and confirm that all Kiosk related triggers are enabled.

//

Warning

Kiosk requires seven triggers to be enabled, each one of a different type. Look in the Item column of the triggers list and confirm that one and only one trigger is enabled per each item type depicted below.

  • financial
  • keycard
  • FaceMatch
  • PMSCall
  • SendTextMessage
  • Validate
  • qrCodeEncode
  • clientErrorLog

If your Kiosk needs to integrate with an external document validation platform (such as STB/EVA), two extra triggers will appear in the UIP's Triggers page:

  • detectFace
  • externalDocumentValidation

Additionally, the following triggers may appear in the UIP's Triggers page:

  • ParseQRCode: when Kiosk needs to be able to parse QR codes generated by a third party online booking system
  • CallAssistance: when Kiosk needs to be able to send assistance requests

Check Adapter Types

Go to UIP's Adapter Types page. If there are any adapter types prompting you for an update, like in the following image, then please proceed with the update. You can use the Update All button to update all adapter types at one.

//

Warning

We recommend checking for adapter types updates periodically, not just after importing files, in order to keep your system updated with latest critical patches and bug fixes.

Check Adapter configurations

  • Go to the Adapters page
  • Click on the Edit link for each adapter
  • Confirm that the configuration per that particular adapter is correct. If you re-import UIP config files using the Replace Existing option, then the original configuration might have been overwritten with the default one.
  • Confirm that all adapters are started