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 |
|---|---|---|
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.
|
8 | Syncing customers from Shared EZLinks Unity to EZLinks API | Check for customers/create customers in EZLinks |
Authentication with RTP and EZLinks
Regardless of which NOP site a customer is created on, the behavior of syncing customer to RTP|One is identical. Flows for how Identity handles create an account, log in, and claim account are detailed here.
NOTE: When guest checkout is turned on with Identity, Guest checkout has to be the prioritized flow. So the guest is first asked if they want to checkout as a guest, and if they opt to log in, they are routed to Identity. If guest checkout is turned on with standard login, either guest checkout or standard login can be prioritized with a setting.
For sites where golf is enabled…
Once an account is created, logged into, or claimed through Identity, or if a guest account is created through Aspenware Commerce (only turned on for Boyne Golf) and once the account is “settled” in RTP (see the documentation for RTP account flows), the following set of events happen to “settle” the account in EZLinks.
A message is sent to Topic in the Service Bus that a customer was created in RTP. We have an EZLinks function that is subscribed to that topic.
When a topic gets a message it tells the EZLinks Function that a customer has been created and the following events are followed to create a customer in EZLinks.
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}")
If a customer does not exist, the customer is created in EZLinks with the following data:
IP Code (stored in InternetUserID), LastName, FirstName, StreetAddress, StreetAddress2, City, StateProvince, ZipPostalCode, CountryId, Phone, Email, sponsorId, ezLinksCountryId
If fields are not present then defaults are set. Address fields default to XX/XXX and phone defaults to 0000000000, country defaults to us
Frequently Asked Questions
Q: I understand that when an account is created, logged into, or claimed we check if the customer exists in EZLinks - what is this match done on? IP code, name, something else?
A: We match on Internet User ID, which is a combo of some prefix (defined in settings) and ip code ("{_settings.InternetUserIdPrefix}{recId}")
Q: When a guest uses guest checkout and buys a tee time, is the same process followed as above, or is a new account always created for guests?
A: Every time a guest enters checkout a new user is created in RTP w/ a new ip code. Since we match on ip code, I believe a new user would be create d in ezlinks each time
Q: What customer data do we send to EZLinks when an account is created? First, Last, (Do we send email, DOB, IP code anything else) what is our key identifier to link customers across systems.
A: IP Code (stored in InternetUserID), LastName, FirstName, StreetAddress, StreetAddress2, City, StateProvince, ZipPostalCode, CountryId, Phone, Email, sponsorId, ezLinksCountryId
If fields are not present then defaults are set. Address fields default to XX/XXX and phone defaults to 0000000000, country defaults to us