Golf Architecture

Architecture Diagram

The following diagram represents the most complete Golf implementation Aspenware offers, including tee-time online booking, online check-in, and pro-shop check-in. Pro-shop check-in (using LS Retail) is only currently supported for Boyne Resorts.

Authentication for a golf implementation can be done through Identity or standard Nop login, and this diagram represents both authentication flows.

 

Step

Label

Note

Step

Label

Note

1

NOP

Nopcommerce also know as Aspenware Commerce powers both the golf customer facing shopping experience and the Pro-Shop Checkin page that appears within LSRetail for onsite checkins.

If multiple resorts are operating golf courses that operate out of separate stores but share a single corporate entity, then there are separate Nops for each resort likely.

2

Identity

Identity is a separate application that enables customers authenticate to Aspenware Commerce and other applications via sign in, create account or claim account flows. Flows for how Identity handles create an account, log in, and claim account are detailed here.

If multiple resorts are operating golf courses that operate out of separate stores but share a single corporate entity, then there is likely a single Identity that all the resorts tie into.

3

LS Retail

LS Retail displays a Nop storefront within LSRetail to power the check-in experience. There are multiple terminals that all run LSRetail and are linked to the NOP store that is configured for its terminal.

4

Unity used for EZLinks

Used for booking and displaying tee time data.

If multiple resorts are operating golf courses that operate out of separate stores but share a single corporate entity, then there are separate EZLinks Identitys for each resort likely.

5

Redis Cache

The Redis Cache is a database that stores tee time information coming from the EZL Xtream Service, RTP & EZLinks Contact Pairings, and Earliest Available Tee Time Information.

If multiple resorts are operating golf courses that operate out of separate stores but share a single corporate entity, then there is likely a single Redis Cache that all the resorts tie into.

6

Xtream Services

The Xtream Service is an EzLinks Subscription Service. EzLinks Unity subscribes to this service to get real-time updates on tee times for all of courses that unity instance. When we get sent a message from the Xtream service, EzLinks Unity will process the message and update the tee time information stored in the Redis Cache (the tee time data that is stored in the redis cache is the same data that is displayed on the PDP).

If multiple resorts are operating golf courses that operate out of separate stores but share a single corporate entity, then there is likely a single Xtream Service that all the resorts tie into.

7

Golf Topic Function/Queuing Process

Calls create customer.

  1. First, it checks to see if the customer already exists in EZLinks.We match on Internet User ID, which is a combo of some prefix (defined in settings) and ip code ("{_settings.InternetUserIdPrefix}{recId}")

  2. If a customer does not exist, the customer is created in EZLinks with the following data:

    1. IP Code (stored in InternetUserID),  LastName, FirstName,Email, sponsorId. If fields are not present then defaults are set.

      1. Address fields always default to XX/XXX and phone always defaults to 0000000000, country defaults to us. These are set to default values because the EZLinks API requires these fields, but the system was not designed to store these fields in EZLInks

8

Syncing customers from Shared EZLinks Unity to EZLinks API

Check for customers/create customers in EZLinks