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 8 Current »

Use this list of items if you are experiencing an issue with Aspenware Scanning. AW Scanning uses Unity just like Aspenware Commerce but some customers have a stand-alone instance of Unity that only the scanners use which is typically installed on an internal server in the customers environment instead of a web server. Because these URLs may differ from the Commerce Unity URL, it’s important to know what URL is configured for the scanning app.

Instructions

Questions to ask and how to test

  1. Has the scanner been working or has it never worked?

    1. If it has been working, has anything in the environment changed, or are you currently having any network issues?

    2. Has there been an RTP upgrade recently? RTP 2022.2 introduced a change to the stored procedure, proc_publicGetPrepaidAccessProfileWithHistory that required a change in Unity. Customers running RTP 2022.2 or greater will need to upgrade Unity to v3.28.

    3. If it has never worked, all settings on the scanner need to be checked (refer to documentation).

  2. What is the Unity URL being used by the scanner? The Unity URL can be found by scanning a barcode of the word, ‘SETTINGS’ on the Login page of the app (or ‘settings’ can be typed in). This will then show a page where the WebServiceURL, ClientID and ClientSecret are entered. Once the URL is known, check the log file on the server which is typically located in C:\inetpub\wwwroot\UnityProd\Logs (or whatever the application directory is named, (UnityProd, UnityProdScanning, etc).

  3. Can the Unity URL be entered into a browser on the device to show the API page or does an error page show? If an error page shows, it’s likely the Unity URL cannot be reached on the wireless network the device is connected to. This is likely a network issue that the customer needs to look into.

    1. The format of the URL in SETTINGS should look like this WITH the trailing slash: https://unity.aspenwarecommerce.net/UnityQA/

    2. To test entering the URL into a browser on the device, it must be entered like this: https://unity.aspenwarecommerce.net/UnityQA/index.html

    3. If the URL shows the API page (not an error page), enter the ClientID and Client Secret to make sure they are valid. Click the ‘Authorize’ button:

      1. Then enter the ClientID and ClientSecret being used

      2. Then check the following scopes (the checkboxes)

        1. service.access / access control service (usually the first one in the list)

        2. services / services (usually the last one in the list)

      3. Then click ‘Authorize’. If the credentials worked, you should see this message. If you don’t, it’s possible the wrong ClientID and ClientSecret were entered.

    4. Then to verify Unity can communicate to the RTP db, try the ‘get access locations' api call

      1. Change dropdown in upper right corner from V1 to V3

      2. Click the entry, GET - /api/Access/locations

      3. Click ‘Try it out’ and then the blue Execute button

    5. If Unity can communicate to the RTP db, you should see a list of RTP Access Locations returned. This is one of the calls the scanner makes so if this works, the communication to RTP is working.

    6. If you see anything other than a list of Access Locations returned, it’s possible Unity can’t communicate to RTP.

    7. If the above is working as expected but the scanners are still experiencing issues, emulate a scan in Swagger using the /api/access/process call. Click ‘Try it out’ and replace the default JSON with the example below.

 

Replace the above with the following but edit the values in bold to match the environment being used for testing.

{"accessEndPoint":{"deviceId":{"ids":[{"infoRecId":"307","infoSourceType":"External"}]},"locationId":{"ids":[{"infoRecId":"50","infoSourceType":"Master"}]},"resource":{"points":0},"resourceId":{"ids":[{"infoRecId":"ch1","infoSourceType":"Master"}]}},"date":"Aug 15, 2022 4:13:28 PM","functionCode":3,"identification":{"barcodeId":"","chipId":"AXM10016386","identificationType":"Media","licensePlateNumber":"","magneticStripId":"","mediaTypeDescription":"","serialNumber":"","username":"admin"},"validateOnly":true}

-locationId":{"ids":[{"infoRecId":"150" - change 150 to an Access Location code in the environment being used for testing

-barcodeId":"","chipId":"AXM10016386" - change to a pass media code or RFID chipID in the environment being used for testing. In IKON environments, using an RFID chipID triggers IKON functionality so even if a pass media code returns a valid scan message, try an RFID chipID as well.

-validateOnly":true - set to true to emulate a validate only scan and false to emulate a real scan.

Click Execute:

Check results. If a valid or invalid scan message appears like below, Unity is receiving back valid messages from RTP and the same result should be showing on the scanner. If errors show instead, Unity may not be getting back a valid message from the RTP stored procedure, proc_AccessProcess. Additional troubleshooting may be necessary depending on the error being shown.

  • No labels