SKIDATA Skiosk Pickup Box (PUB)

This solution supports the use of the SKIDATA Skiosk to print media from an RTP order or sales transaction. Sales that contain deferred printable media from RTP are uploaded to SKIDATA’s SWEB tool which can then be printed on the Skiosk. Once printed, SKIDATA sends the RFID back to RTP and marks the media as printed. The media can then be used for validation in RTP.

Solution Overview

There are 4 main aspects to this solution. 1) SKIDATA DTA/SWEB, 2) Unity Contractor Service, 3) Unity DTA Jobs, and 4) RTP.

 

SKIDATA DTA/SWEB

SKIDATA provides access to SWEB during the implementation and will also provide training on the tool. Typically SWEB is accessed often during the initial implementation phase to verify interfaced products and orders but then less after go-live. The interface between Aspenware and SKIDATA only uses a small portion of SWEB which is also used with SKIDATAs POS and parking system.

SKIDTA Skiosks

This is the hardware that prints RFID cards (shown above).

DTA

This is the name of the interface used by a 3rd party system to interact with SKIDATA’s system.

SWEB

SWEB is the name of the user interface used by the SKIDATA Skiosks and can be used to view interfaced products and orders. The printing template the Skiosks use is also defined in SWEB.

Unity Contactor Service

The Unity Contractor Service is an Aspenware-created Windows IIS application that is installed locally at the resort. The application is used for for 2 purposes which are to create products in SKIDATA’s SWEB application (via the catalog import function) and to upload the RFID from the Skiosk back into RTP and to mark the media as printed.

An RTP Client Code is defined in the SKIDATA SWEB tool which is used in the catalog import process to lookup products in RTP that are eligible to be printed on the Skoisk. A product is created in SWEB for each RTP product and a mapping is automatically defined to the RTP product header code. Only products that are interfaced to SWEB through the catalog import process are then eligible to printed on the Skiosks. Once printed, SWEB sends the RFID back to the Unity Contractor Service where it is uploaded into RTP’s ExternalAccessMap table and the media is marked as printed in the TransactionProductOutput table.

Unity DTA Jobs

The Unity DTA Jobs service is also an Aspenware-created Windows IIS application that is installed locally at the resort. This application polls RTP’s TransactionProductOutput table every minute for new records. Only transactions with products that have previously been interfaced to SKIDATA’s SWEB tool (via the catalog import) will be picked up by the service and sent to SKIDATA to create an order. An Order is created in SWEB with a reference to the RTP Sales Transaction ID, Order ID or External Order ID which is used to retrieve the order and print (usually from a QR or barcode).

RTP

RTP sales transactions and fulfilled orders that contain deferred media of season pass and access products are eligible to be printed on the Skiosks. As mentioned previously, the products must first be included in the catalog import process and interfaced to SWEB before a sales transaction or fulfilled order containing deferred media will be created in SWEB as an Order.

RTP Client Code

The RTP Client Code defined in SWEB will be used by the catalog import to lookup which products meet the criteria to be included in the import process. Products must be priced in RTP for the day the catalog import runs.

An existing RTP Client Code can be used or a new one can be created. The Sale Location assigned to the Client in RTP can also be an existing sale location or a new one dedicated to a new Skiosk Location. The benefit of using a new sale location is that products could be priced for all dates. If products are only priced for part of the year, it is likely multiple catalog imports will need to be performed in order to interface those products to SWEB making transactions and orders that contain these products eligible to be printed on the Skiosks. If products are available all season, then it is possible only a single catalog import will need to be run at the beginning of the season.

The Client Code will also be uploaded into several RTP tables as the client code that printed the media (i.e. TransactionProductOutput.OutputClientCode).

 

Detailed Setup Guide

The following instructions detail the setup steps for using the SKIDATA Skiosk to print media from an RTP order or sales transaction.

  1. Set Up SWEB Contractor

  2. Import SWEB Catalog

  3. Configure SWEB Print Mask (Media Template)

  4. Install Aspenware IIS Application

  5. Test UnityDTAJobs Install

  6. Trigger Sending of RTP Transactions to SKIDATA/SWEB

  7. Select Testing Method

  8. Add Rules to Product Header Codes

  9. Go Live

1. Set Up SWEB Contractor

The Unity Contractor Service URL is define in SWEB which is where SKIDATA will configure a Contractor entry. Aspenware will provide the URL to the Unity Contractor Service once it is setup or will add the URL to SWEB. This can be found in SWEB in Sales Management / Tenants / Contractors.

Following is an example from Aspenware’s test environment.

  1. Edit the Contractor entry and then navigate to the Contractor System tab to define the URL.

2. Click ‘Check Connectivity’ to test the connection from SKIDATA’s SWEB tool to the Unity Contractor Service installed locally at the resort. The URL format is below but will differ for each install = https://servername.com/UnityContractorService/ContractorService.svc

2. Import SWEB Catalog

SKIDATA will configure portions of SWEB prior to the first catalog import. The catalog import can be found in SWEB in Sales Management > Configuration > Catalogs and there is typically only one entry created for the resort. The RTP Client Code that will be used to lookup products in RTP is defined in the External ID field (see below). At least one catalog import will need to be completed prior to any attempt to print from the Skiosks.

  1. To start the catalog import, click the Import button along the top ribbon. Then click Start Import.

2. The import process only takes a few seconds. To view the products imported, click the Products button along the top ribbon.

3. If the import was successful, products will show in the list. Use the gear/settings icon to show the External Id column which shows the RTP Product Header code.

 

3. Configure SWEB Print Mask (Media Template)

The catalog import also configures a Print Mask in SWEB which is the media template that prints when a Skiosk order is fulfilled. This is located in Sales Management > Configuration > Print Masks. Each time the catalog imports runs, the print mask gets set back to the default which some customers do not use. It is recommended to define the Print Mask during testing and then to export the template from SWEB and then re-import after each catalog import.

The default template pulls a description from one of the Unity Contractor Service configuration files so this could be used to define a short text line on the template (e.g., Winter 22-23). Some customers use this and therefore need to remember to update the configuration file after each season. Each time the configuration file is updated, a catalog import will need to be performed to add the new descriptions to SWEB. The text is located in the web.config file in the DTA ticketText field. Additional information can be found on this in the install section of this guide.

 

  1. Double click the entry above to edit the template.

2. To export the template, click Miscellaneous in the upper right corner and then the Export button. This will download a JSON file that can be used to import the template using the same method after the next catalog import.

3. To import, click the Import Template button.

4. Install Aspenware IIS Application

Aspenware will perform 2 installations on Unity in conjunction with this implementation.

Install Unity Contractor Service

Aspenware will install the Unity Contractor Service on a server at the resort that is accessible to the SKIDATA web services. SKIDATA will provide the IP range of the traffic so that the server can be locked down. The Unity Contractor Service is an IIS application that is accessed by SKIDATA for the catalog import function and to upload printed RFID’s to RTP.

The following config/json files contain all the configuration values needed for the service.

  • Rtp-config.json – contains all RTP configuration values

    • SalesChannelCode: Sales channel used for the product catalog import. Products need to be priced for the day the catalog imports runs and to have output added in RTP for the sales channel defined.

    • UserID: This must be a valid user with a valid UserSession.SessionToken in RTP. This user will be the OperatorID that printed the media in several RTP database tables.

    • Database Connection string (server, db, SQL user): Aspenware will create a new SQL Role and User and the Role needs to have privileges to the following tables. Aspenware can configure this in SSMS or provide a script.

      • GRANT SELECT ON [dbo].[TransactionProductOutput] TO [awdtarole]
        GRANT UPDATE ON [dbo].[TransactionProductOutput] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLineOriginalTransactionLine] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionHeader] TO [awdtarole]
        GRANT UPDATE ON [dbo].[TransactionHeader] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionProductOutput] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionProduct] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLine] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLine] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLineIp] TO [awdtarole]
        GRANT SELECT ON [dbo].[PersonProfile] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLineExternalOrder] TO [awdtarole]
        GRANT SELECT ON [dbo].[TrueFalseRule] TO [awdtarole]
        GRANT SELECT ON [dbo].[RuleHeader] TO [awdtarole]
        GRANT SELECT ON [dbo].[PassMediaProfile] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLineProductHeaderPrompt] TO [awdtarole]
        GRANT SELECT ON [dbo].[ExternalAccessMap] TO [awdtarole]
        GRANT SELECT ON [dbo].[UserID] TO [awdtarole]
        GRANT SELECT ON [dbo].[UserSession] TO [awdtarole]
        GRANT SELECT ON [dbo].[CompareRule] TO [awdtarole]
        GRANT SELECT ON [dbo].[ProductProductHeaderLink] TO [awdtarole]
        GRANT SELECT ON [dbo].[TaxLocation] TO [awdtarole]
        GRANT SELECT ON [dbo].[ProductTax] TO [awdtarole]
        GRANT SELECT ON [dbo].[Tax] TO [awdtarole]
        GRANT SELECT ON [dbo].[AccessSummary] TO [awdtarole]
        GRANT SELECT ON [dbo].[CustomerIP] TO [awdtarole]
        GRANT SELECT ON [dbo].[EmailProfile] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionProductPassMedia] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionProductOutput] TO [awunityrole]
        GRANT SELECT ON [dbo].[AccessDailySummary] TO [awdtarole]

    • ClientCode: Client code used for product catalog import.

    • SaleLocationCode: Sale location used for the product catalog import.

    • AuditLocationCode: Not used but set to the same location code above.

  • Web.config – contains additional setup data

    • Skiosks: Defines mapping for SKIDATA Skiosk and RTP Client code. This client code will be updated in RTP’s TransactionProductOutput.OutputClientCode column as the client that printed the output and shows in various places in RTP. Currently on a single mapping is supported by SKIDATA. Define the SKIDATA Sales Channel name to map to the RTP client code in this section.

    • ticketText: Text data is imported during catalog import to SWEB/Print Mask, ‘Text Print Mask Item 1’. If text is changed directly in SWEB, data will be overwritten with text defined in web.config in next catalog import. If this media element is not added to the Print Mask in SWEB, there is no need to update this from season to season.

    • priceCategoryName: Text data is imported during catalog import to SWEB/Price Category. This description does not show during fulfillment but does show in SKIDATA admin. Typically this description is set to match the same description of ticketText above.

    • seasonStartDate & seasonEndDate: Dates are imported during catalog import to SWEB/Time Periods. Aspenware recommends defining a large data range to avoid having to update each season since this data only shows in SKIDATA admin.

  • Test the Unity Contractor Service install by entering the URL into a browser to verify a service page displays instead of an error page.

Install Unity DTA Jobs

Aspenware will install the Unity DTA Jobs on a server at the resort that is accessible to the SKIDATA DTA web services. SKIDATA will provide the IP range of the traffic so that the server can be locked down. The Unity DTA Jobs is an IIS application that is used to look up transactions in RTP that have deferred output and to create orders in SKIDATA’s SWEB application. Microsoft’s dotnet-hosting will also need to be installed on the server hosting the UnityDTAJobs application.

The UnityDTA Jobs service uses Hangfire which is a 3rd party product used to perform background processing in .NET and .NET Core applications. Hangfire has several database tables that will also need to be deployed which are described below.

Install UnityDTAJobs database

Aspenware has scripts to install the UnityDTAJobs database which also include database tables for Hangfire. These tables track which RTP transactions have been sent to SKIDATA/SWEB. See below for screenshot of the tables included in the UnityDTAJobs database.

Configure UnityDTAJobs

The following config/json files contain all the configuration values needed for the UnityDTAJobs service.

  • appsettings.json Used to define database connection info to the Hangfire database tables.

    • DBConnString: Define server and database hosting Hangfire database tables.

    • SyncReservationsBatchSize: Defines the batch size for syncing RTP transactions to SWEB. Default is 100.

    • SyncReturnsBatchSize: Defines the batch size for syncing RTP return transactions to SWEB which cancel a previously created order. Default is 100.

    • SyncPrintUpdatesBatchSize: Defines the batch size for syncing print updates. Default is 100.

    • EmailSettings: Used to define SMTP email server info for alerts when an error occurs syncing RTP transactions or cancellations to SKIDATA.

  • skidata-config.json: Defines SKIDATA production URL’s for the DTA interface. Typically these do not change.

    • Client: Define the SKIDATA DTA Tenant (from SWEB)

    • WorkingClientName: Define the SKIDATA Sales Channel Name (from SWEB)

    • PointofSaleName: Define the SKIDATA Sales Channel Name (from SWEB)

    • User/Password: Define value username/password from Sales Channel setup in SWEB (typically Skidate provides this)

  • rtp-config.json: Defines RTP server connection info and other RTP related setup.

    • UserID: This must be a valid user with a valid UserSession.SessionToken in RTP. This user will be added to transactions that have been interfaced to SKIDATA SWEB.

    • Database Connection string (server, db, SQL user): Aspenware creates a new SQL Role and User and the Role needs to have SELECT privileges to the following tables. Aspenware can configure this in SSMS or provide a script.

      • GRANT SELECT ON [dbo].[TransactionProductOutput] TO [awdtarole]
        GRANT UPDATE ON [dbo].[TransactionProductOutput] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLineOriginalTransactionLine] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionHeader] TO [awdtarole]
        GRANT UPDATE ON [dbo].[TransactionHeader] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionProductOutput] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionProduct] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLine] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLine] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLineIp] TO [awdtarole]
        GRANT SELECT ON [dbo].[PersonProfile] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLineExternalOrder] TO [awdtarole]
        GRANT SELECT ON [dbo].[TrueFalseRule] TO [awdtarole]
        GRANT SELECT ON [dbo].[RuleHeader] TO [awdtarole]
        GRANT SELECT ON [dbo].[PassMediaProfile] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionLineProductHeaderPrompt] TO [awdtarole]
        GRANT SELECT ON [dbo].[ExternalAccessMap] TO [awdtarole]
        GRANT SELECT ON [dbo].[UserID] TO [awdtarole]
        GRANT SELECT ON [dbo].[UserSession] TO [awdtarole]
        GRANT SELECT ON [dbo].[CompareRule] TO [awdtarole]
        GRANT SELECT ON [dbo].[ProductProductHeaderLink] TO [awdtarole]
        GRANT SELECT ON [dbo].[TaxLocation] TO [awdtarole]
        GRANT SELECT ON [dbo].[ProductTax] TO [awdtarole]
        GRANT SELECT ON [dbo].[Tax] TO [awdtarole]
        GRANT SELECT ON [dbo].[AccessSummary] TO [awdtarole]
        GRANT SELECT ON [dbo].[CustomerIP] TO [awdtarole]
        GRANT SELECT ON [dbo].[EmailProfile] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionProductPassMedia] TO [awdtarole]
        GRANT SELECT ON [dbo].[TransactionProductOutput] TO [awunityrole]
        GRANT SELECT ON [dbo].[AccessDailySummary] TO [awdtarole]

      • Privileges to UnityDTAJobs database tables:

        • GRANT SELECT ON [dta].[LastProcessedTransaction] TO [awdtarole]
          GRANT UPDATE ON [dta].[LastProcessedTransaction] TO [awdtarole]
          GRANT SELECT ON [dta].[Reservation] TO [awdtarole]

        • GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA :: HangFire TO [awdtarole]
          GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA :: dta TO [awdtarole]

5. Test UnityDTAJobs Install

Once installed, navigate to http://localhost/UnityDTAJobs/hangfire/ in a browser on the machine hosting the application. If the install was successful, the Hangfire Dashboard should show rather than an error page. The Realtime Graph below shows the number of transactions processed and the History Graph shows the total uptime of the Hangfire service.

6. Trigger Sending RTP Transactions to SKIDATA/SWEB

The UnityDTAJobs IIS application uses the dta.LastProcessedTransaction table to track the transactions that have already been sent to SKIDATA. During the implementation, the ProcessDate will be set to a date in the past and will begin processing once the IIS application is started. Once the date catches up to the current date, only new transactions containing deferred output will be processed moving forward.

Every RTP transaction is reviewed by the service to see if there is any deferred output that meets the criteria to be sent to SKIDATA to create an order. The criteria is that the product in the transaction has been previously interfaced to SKIDATA using the product catalog import and that the product has the Rule, ‘Skidata Print PUB’ added (See rules information below). Each RTP transaction ID that meets the criteria, will be created in SWEB as an Order and the DTAOrderID will be recorded in the dta.Reservation table.

The DTAOrderID will also be updated into RTP’s TransactionHeader table in the OfflineTransactionID field.

Below shows an Order in SWEB created from RTP Transaction ID, 101525809. If the order originated from an Aspenware online order, the ConfirmationNumber will be the RTP ExternalOrderID (i.e. PK12345).

7. Select Testing Method

It is possible to point all the services to RTPOneTest to perform testing but it is easier to test against RTPOne prod instead. The main issue with using RTPOneTest is that SKIDATA does not have a test system so it’s possible that an RTP TransactionID that was interfaced to SKIDATA/SWEB during testing from RTPOneTest will exist in RTPOne production as a real customer’s TransactionID. The SKIDATA development team can clear out orders that were created during testing but using the method below against RTPOne prod is preferred for testing.

Below is an outline to perform initial testing without interfacing all RTP transactions to SKIDATA SWEB.

  1. Set the dta.LastProcessedTransaction table to have a ProcessDate of today for all rows.

  2. Recycle the UnityDTAJobs application pool (or start the service).

  3. Create or clone an RTP Product Header that contains media output that has never been sold to a customer and add all three Skiosk related Rules (Unity Attribute - Age, Unity Attribute - Duration, and SkiData Print on PUB).

  4. In SKIDATA SWEB, start the product catalog import and verify the new product shows up

    1. If no product, review the SWEB DTA Transaction Logs for any errors.

    2. If no errors in DTA Transaction Logs, review the UnityContractorService log

    3. If no errors in the UnityContractorService log, start SQL trace to see call hitting RTP and manually run in SSMS. This may reveal that the product does not meet the criteria to be interfaced (pricing, sales channel, sale location, etc).

  5. In RTP, create a sales transaction and sell the product created in step 1 above. Make sure to defer media during the sale.

  6. In SWEB, make sure you see an Order show up within a minute or two.

    1. If no order in SWEB, verify the UnityDTAJobs IIS application is running (verify the application pool is started).

    2. If UnityDTAJobs is running, check error log.

    3. If no errors, verify there is deferred output in RTP’s Deferred Output Tool.

    4. Check the UnityDTAJobs table, dta.Reservation for the most recent entries to see if there are errors.

  7. Create a barcode or QR code of the RTP TransactionID and attempt to use at Skiosk.

    1. If nothing prints, re-verify the Transactions is in SWEB as an Order

    2. If Order exists but nothing prints, ask SKIDATA to check the Skiosk log (which is located directly on the PC inside the Skiosk hardware.

    3. If media prints, verify the RFID can be used to perform a search in RTP.

      1. If RFID cannot be searched successfully in RTP, look for errors in the UnityContractorService log.

  8. Repeat steps above for an RTP OrderID that is manually created and fulfilled in RTP and for an online order.

    1. For an Order created directly in RTP, use the RTP OrderID as the barcode/QR code at the Skiosk.

    2. For an online order, use the RTP ExternalOrderID as the barcode/QR code at the Skiosk.

8. Add Rules to Product Header Code(s)

Three Product Header Rules need to be added to any product that will be printed from the Skiosk.

IMPORTANT: DO NOT ADD THESE RULES UNTIL GO-LIVE. More info on this can be found in the testing section of this document below.

Rule 1: Unity Attribute - Duration

Add Duration rule to Product Header Codes per the diagram and define a value of 1.

Rule 2: Unity Attribute - Age

Add Age rule to Product Header Codes per the diagram and define a value of 1.

Rule 3: SkiData Print on PUB

Add SkiData Print on PUB Rule to Product Header Codes and define a value of TRUE.

Configure Product components to have Output and to Allow Deferral.

NOTE: If after go-live, the resort realizes they did not add the three Rules to all products, the catalog import can be run again and the ProcessDate in the dta.LastProcessedTransaction can be set back to a date in the past. The service will run and skip over any transaction it has already processed and only create orders in SWEB for transactions containing the new products. This process will also take a few hours because every transaction is reviewed again by the service.

9. Go Live

Going live with the Skiosks means ensuring all products in RTP have the three rules added and then setting the ProcessDate in the dta.LastProcessedTransaction to a date in the past. If the testing method above was followed, there should be no need to clear out data in the dta.Reservation table.

  1. Stop the UnityDTAJobs application pool.

  2. Ensure the 3 product header rules have been added to all products.
    (SEE SECTION ABOVE)

  3. Start the product catalog import in SWEB

    1. Ask the resort to review the list of products. If products are missing, ask the resort to add the three Rules to additional products and/or verify the product(s) are priced for ‘today'.

    2. Repeat this step until the resort verifies all products are showing in SWEB.

  4. Set the dta.LastProcessedTransaction table to have a ProcessDate in the past. This should be the date of or right before the date they started selling media products for the season.

  5. Start the UnityDTAJobs application pool.

  6. Verify Orders are showing in SKIDATA SWEB. This process can take a few hours depending on how far back the date goes and how many total transaction's the resort has.

  7. To verify the initial load of Orders is complete, verify the ProcessDate for the Reservation column now shows today’s date.

Orders Creation in SWEB from RTP Sales Transactions

The Unity DTA Service is always running in the customer’s environment and is looking for new RTP transactions that contain deferred pass media and access output. The products in these transactions need to have the Product Header Rule, SkiData Print On PUB and the products must currently be in SWEB from a catalog import. If all these conditions are met, an Order gets created in SWEB which can be viewed in Sales Management > Monitoring > Orders (see below). Once the Order is created in SWEB, it can then be printed from the Skiosk. If an order or is cancelled in RTP or the fulfillment transactions has been returned, the order is then cancelled in SKIDATA/SWEB and cannot be printed.

The ‘Confirmation Number’ that appears in SWEB will be the RTP Sales Transaction ID if the deferred output is associated with an RTP sales transaction (completed directly in RTP), an RTP OrderID if the deferred output originated from an RTP order (completed directly in RTP), or the ExternalOrderID if the sale originated from an Aspenware order (or any 3rd party processing orders into RTP).

This is the only value mapped to the SKIDATA Order and is the only value that can be used to find and print the order on the Skiosk. In other words, for an Aspenware order, only the ExternalOrderID will get mapped to the Order in SWEB so only that value can be used to find the order and print the media from the Skiosk. The RTP OrderID from Aspenware’s order cannot be used to find the order in SWEB.

Ongoing Support and Maintenance

Depending on the products being printed on the Skiosks, additional product catalog imports may need to be run in the future. Some resorts have very few products that haven’t changed from year to year so they may have only used the catalog import function during the initial implementation. Resorts that are not bundling media with access on product headers may have very few media product headers and therefore very few interfaced products in SKIDATA/SWEB. Resorts that bundle media and access may have dozens or hundreds of products interfaced to SKIDATA/SWEB.

The key thing to remember is that ‘todays’ date is used when the catalog import runs so if a resort does not have pricing setup until their opening date (i.e. 11/15/2024), then running the catalog import in October will not interface products to SKIDATA/SWEB.

As mentioned above, each time the catalog import is run in SWEB, the Print Mask resets back to the default so if the resort isn’t using the default, they will need to import the Print Mask file after each import.