RFC: Sitecore XConnect/XP Recommended Practices

[nickwesselman]

Helix should include recommended practices for Sitecore XConnect, which provide for long-term maintainability and shared conventions across the community.

• Sitecore XP development may require developing on, and deploying to, multiple targets/subsystems. This is a general concern discussed in RFC: Multiple Deployment Targets #22 and addressed by @robearlam for Commerce in this pull request.
• Any recommended practices for schema design?
• Any recommended practices for schema deployment to all necessary services?
• Any specific practices around use of Tracker or Universal Tracker?
• Other conventions/best practices which Helix should document?

[chorpo]

I think that Helix should be agnostic of Commerce, xConnect, Universal tracker, publishing service and various other newly introduced services. Helix should be kept as best practices for Sitecore overall. Sitecore should rather create more Privacy Guide / xConnect like specific guides for these services.

[nickwesselman]

@chorpo By this reasoning, there should not be practices in Helix for template structure, as this is specific to XM. We want Helix to be a recommended practices guide for the entire platform, towards the goal of ensuring more maintainable and standardized implementations.

[toddmitchell]

Here are a few other best practices that could be included. (i'll try to add more later when time permits)

• Usage of calculated facets, how to create and deploy. various examples of how to use them, and performance impact
• XConnect plugins - how create them and ensure low performance impact
• Xconnect data importer, working in batches of data from 3rd party system while a system is already under load
• Reference data - batch importing, updating, and re-syncing data
• Sitecore Cortex (or classic processing system) - custom processor to create insights on a given batch of contacts that can later be used for personalization (for returning visitors)
• Custom marketing automation plan widgets (i.e. something that calls out to a third party system to send a notification or validate something like a credit check) (and by widget by i mean activity, sorry Al)

[dsolovay]

I have mixed sentiments here. On the one hand, I like the idea of the Helix guide growing to encompass the increasingly rich Sitecore ecosystem. On the other hand, there is real value in having the guide be something that can be digested in a sitting or two. If it becomes a book, rather than a pamphlet, that accessibility will be lost.

One possibility for addressing this tension is to have a core helix document, that focuses on Sitecore's XM roots, and satellite documents that address areas such as Commerce, xConnect, EXM, and Marketing Automation. The satellite documents could be fairly short, as they would not have to cover the foundational principles, while still delving into the intricacies and challenges of each component.

@chorpo By this reasoning, there should not be practices in Helix for template structure, as this is specific to XM. We want Helix to be a recommended practices guide for the entire platform, towards the goal of ensuring more maintainable and standardized implementations.

I disagree with this distinction. XM is foundational to Sitecore, and it is impossible to conceive of a Sitecore implementation without templates, for example. But it is entirely reasonable to imagine a Sitecore solution without Commerce plugins or Marketing Automation campaigns, or even custom Page Events, so it is reasonable that these be treated as secondary concerns from an organizational perspective, and addressed in satellite documents.

[anderslaub]

If there is no mention of other than website implementation in Helix then partners is much more likely to come up with varying implementations thus lower the benefit of us having this set of shared common practices.

It may be a bit premature to provide detailed conventions for xconnect and especially commerce since both are still evolving rapidly. Some high level conventions on structuring and naming could be defined now though. The same applies for Identity and in general Sitecore.Framework that already comes with its own set of conventions.

As @robearlam points out in #22 there is a need in the Helix docs to name project root folders in a module to explicit state the instance type that the project targets through naming the folder accordingly. A module may have multiple projects targeting different instance types. This will probably become much more common going forward.

The name code is too general since all modules in a solution does not necessarily target the same instance type anymore. I highly encourage that the convention going forward will be to name the folders according to target - "website", "commerce", "xconnect", "identity".. etc. as Rob suggests in the PR.

For existing solutions where the build may be dependent on the folder naming should of course just keep the code name for website - only adapt to the updated conventions if it provide value. "monkey see, monkey do" is always better than mixing different practices.

[bill-barron]

I have been looking around and found something like this for helix. Has anyone else seen similar structure? perhaps use separate folders /cm and /cd instead of /code and it starts to look pretty organized.

/src
    /Project
        /MySite
            /code
                MyCompany.Project.MySite.csproj
            /identity
                MyCompany.Project.MySite.Identity.csproj
            /xc-search
                MyCompany.Project.MySite.XConnectSearch.csproj

[nickwesselman]

Hi @bill-barron -- Yep this is the direction we are going. See RFC #22 and Pull Request #15. Instead of code the proposal is website, though as you say if you want/need to separate cm and cd code, you could certainly do that.