Introduction
One might expect there to be many differences in the way SCpbMD works with AX 2012 vs Dynamics 365 for operations (D365). In fact, this is not the case.
From a functional standpoint, the two “flavors” of SCpbMD have exactly the same functionality with the exception of how authentication is handled (will get to this later).
The major difference is how the data stored in the retail channel database is retrieved.
Very simply put the AX 2012 flavor makes a direct SQL connection to the channel database via the commerce runtime (CRT) assemblies. While for D365, the retail server is used exclusively as per Microsoft best practices. All the underlying Sitecore pipelines and 98% of the reference storefront code is exactly the same.
Note: The functionality described is for the Sitecore commerce powered by Microsoft Dynamics reference storefront i.e. the example site. The functionality is 100% customizable, the implementation partner or the client can choose to completely replace the storefront and all authentication methods with their own if they choose to do so.
SCpbMD Authentication explained
Reference storefront (frontend)
Dynamics 365 for operations authentication
When the user registers on the site they must first be authenticated using a 3rd party OAuth provider which has been configured in D365. For example, Facebook, Windows Live or Google. D365 allows for any number of 3rd party providers to be set up to handle authentication on behalf of the D365 retail server.
The user is authenticated by the 3rd party OAuth provider (Facebook etc) if the Sitecore user does not exist it is created, then the Retail server is called using the access token from the OAuth provider and the retail server retrieves the data from the channel database. So although there is a Sitecore user created it is not used for authentication.
Microsoft refers to this form of authentication with the Retail server as “C2 authentication” or “customer authenticated”. Click here for a good overview of how C2 authentication works.
Dynamics AX 2012 authentication
When a user registers on the site a Sitecore user is created and the AX customer is linked to the Sitecore account. When calls are made to the CRT and then in turn to the channel database they are done using the SQL connection settings used by the CRT. These “impersonation” settings are stored in a config file in the transaction service, this is just a connection string to the channel database.
The user is created and authenticated in Sitecore then the final retrieval of data from the channel database is made using the credentials used for the CRT SQL connection in the Sitecore transaction service.
Note: The Sitecore transaction service is simply a web service wrapper around the CRT.
Summary
The big difference between the AX2012 and D365 flavors authentication mechanisms is that for D365 the call to the Retail server is done using the token for the actual user of the site, not an impersonated account. While for AX 2012 the final calls are inadvertently impersonated because of the one SQL connection string used by the CRT.
Dynamics + Sitecore = Commerce 
Nice blog post. I wouldn’t waste that much time to figure out how this work if I found this blog post earlier. 🙂
From my current understanding, every time when user registers via storefront website, the crt will create a customer account in channel database, alternative if there is a cusomter account has an email being pushed to channel to database from AX, user can register by linking to the customer account with the email stored in the channel database.
If above assumption is correct, my question is what would happen if the same email has been registered from storefront first, later AX create another customer with the same email pushed to channel database, are these two customer accounts being auto connected to the same sitecore user login?
Thanks
LikeLike
Hey Vincent, I assume you have the answer for this already :). Don’t check these comments often, you know you can just email me right? 🙂
LikeLike