Wednesday, May 15, 2019

Setting up Sitecore Connect for Salesforce and how to work with a Sandbox

When installing one of the various Sitecore Connect for Salesfoce connectors that can be found here:

https://dev.sitecore.net/Downloads/Salesforce_Connect.aspx

You may run into problems when moving through the various steps in the case that the Salesforce environment you are using is actually a Sandbox environment.

The various steps of the installation are actually pretty straight forward. they are described in much more detail in the specific installation guides but the information below gives you a good overview of the complexity and specific highlevel steps. And it adds just that little extra sauce in case you are using a sandbox environment:

- Install the correct DEF framework (2.0.1 and onwards)
- The 3 providers (Salesforce CRM, Sitecore and xConnect)
- Sitecore connect for Salesforce

Once these pre-requisites are set up, it is time to Convert the installed xConnect Model to JSON and deploy it onto the xConnect roles (xconnect server and indexing server)

Next, log into your Salesforce environment and create your Salesforce connected App. In case that you can't find your way around that environment (like me), switch into the Classic user interface. To do that, just click on your username (right top) and find the option underneath your user menu.

Next up is connecting your Sitecore environment with this Salesforce environment.
In order to do that you'll need 5 specific values to help you construct a specific connectionstring.
- User ID
- Password
- Security Token value
- Client consumer key
- Client consumer secret

The first two are pretty straightforward, the security token is coupled to your account and needs to be reset in order to retrieve it via your configured email address. And the two last ones are retrieved from the connected app that we just configured.

Doing all the above steps will lead you to something that should look like this:

<add name="mysf" connectionString="user id=someone@email.com;password=b;client
id=GEH9zlTNB8o8BA45pAeDtC8W.DIqrAzuzkmPwjz8KF_vzWY8dNIfurWHpfb
ZPGdtc3b;secret key=5468568999798354123;security

token=g3ygFuNzGgm33YTfsM3WKG3AA" />

Next steps is to set up a tenant and configure the endpoints.
However, that is where things started to go wrong for me.
In itself, the configuration of the Salesforce endpoint is nothing more defining the name of the connectionstring we just defined (in this case "mysf"). Once you finalize this you can test the setup by clicking "Run Troubleshooter".

In my case this resulted in:



So, what went wrong?
After some inspection into the log I noticed the following:


After looking around on the internet for a while and contemplating a possible logical cause, the only outcome could be the use of a Sandbox Salesforce environment instead of a standard environment.

It was time to dive into the DLL's and find out what call Sitecore was making exactly.
I found the following in the AuthenticationClientSettings class of the Sitecore.DataExchange.Providers.Salesforce.dll file.


So, even though that endpoint was hardcoded, there apparently was a flag built in that keeps the Sandbox setting in check. But no documentation is available on this flag or how to set it...

Next step, the SalesforceClientEndpointConverter class:



So, there we have it...
Plain and simple:

Adding "sandbox=true" in your connectionstring will resolve your problems...

Glad to see that this option was built in. However, having proper documentation on this might have helped :)

And of course, to prove it, let's press that button again:





Monday, February 25, 2019

Awarded - Most Valuable Professional 2019

 A little while back, end of January to be precise, I was awarded the Sitecore Technical MVP award for 2019.
I am a little late to the announcement party, at least here on my blog. Which doesn't mean it doesn't merrit the much deserved attention and appreciation!


Now,

what does one have to do to achieve the MVP level?
Well, that is one of the reasons that this blog is rather late.

I don't get to spend a lot of my time on social accounts, blogs, stackexchange and even slack.
Meaning that it is a lot harder to get visibility through digital presence if you are not constantly on those channels.

My job mainly consists of following up on projects, providing estimates, knowing everything there is to know about Sitecore, both functionally as well as technically and which restrictions come with that.

So, setting my goals for 2019; what do I want to do with Sitecore?

- Set up a whole lot of instances on 9.1 for testing, upgrades and new customers.
- Keep on hosting the SUG as every session is very well received and keeps on being interesting
- Explore new possibilities with Sitecore. I think a good part of that focus could go into:

  • Cortex: what can Sitecore do out of the box?
  • OMNI:  how is Sitecore handling and approaching all the headless questions at hand
  • Commerce: With their B2C element well rolled out, what is next?
  • Sitecore Horizon and new SXA developments
  • Sharpen even more Azure experience in myself and the team
  • Salesforce keeps on growing closer to Sitecore, what's up and what's possible?
Regardless to say that there are quite some challenges up ahead that we are looking forward to tackle!

I'd like to finish of by saying, again (!), that I am truly honored to be counted among all these brilliant minds and look forward to exchange knowledge and ideas again in 2019!

See you all in London for SugCon!






Friday, October 26, 2018

SXA Data folder behavior

Let me start of with a general clarification for those of you who have little to no experience with SXA.
With Sitecore Experience Accelerator, data sources can still be stored in multiple places. And by default, your page's datasources will be stored either under a site-wide data folder node or the data folder located underneath your actual page.
Meaning that everything related and uniquely linked to a page is simply nested underneath that page and those blocks of content that allow further re-use are found on a higher data-repository level.

When adding a new component you are presented with the following option to select or create a new piece of associated content:



However, from time to time some unexpected behavior might pop up. Sitecore, by default, will use the Sitecore GUID as reference point for the datasource location in your presentation properties.
However, with SXA, the relative path of your datasource is used instead


SXA chose this approach to make the behavior more logical for end-users. Because when you copy a page with this approach, you actively create new nested datasources that can be modified within the scope of that page and that page alone.
When a reference is made based on the datasource Id, copying a page A to create page B results in cross references between B and A. So when a block of content is modified on page A, that same change will become visible on page B as well.

Now, back to the essence of this blogpost ;)


One of our customers had reported strange behavior with one of the created pages. 
Out of the blue one of the pages was displaying the wrong information inside the Experience Editor whereas the information portrayed on the published site was still correct.

On detailed inspection we came to the first conclusion that the datasource that pointed to the Data folder (in this case: local/Data/Text3) did not actually use that datasource...
Inside the Experience Editor if you clicked the : "Edit associated content" the editor jumped into an item nested underneath another item (an SXA redirect in this case) that had its own Datafolder with a Text3 item...

Changing the name and location of this Text3 item did indeed change the behavior of the Experience Editor to use the correct child datasource item again. Meaning that the problem must be somewhere in how Sitecore resolved which datasource to use.

So, what was going on? The customer had created a redirect page with the same name as another item in Sitecore (our problematic page) but had assigned a display name on that item.
Since the redirect page was higher up in the hierarchy of the Sitecore tree, when the Experience Editor was resolving the datasource for Text3 it was doing this by path. And apparently SXA replaces "Local" by the actual full Sitecore path instead of looking for child items.

This resulted in the redirect item to be found as the actual item where new and existing changes for the datasources should be created and searched.

The solution was a simple as the reason that this problem came to be: change the name of the problematic page to the displayname that das been assigned.
Since the redirect item handled the original url/path it could now safely redirect to the target page, which in turn was able to resolve it's datasources to it's own child pages.

Conclusion 

Be careful around the current implementation of path-based datasource resolution. As Sitecore allows for items to have the same itemname (GUID is different so Sitecore is fine) resolving paths will always end up with the first hit in the hierarchy.

Switch between Path or Guid datasource


Keep in mind however that SXA provides script that help you switch from the path based approach into the ID based approach. 

So, if for any reason, the path approach is not sufficient you can use the following:



Thursday, June 28, 2018

Setting SXA security roles (with a small twist)


General setup 

 After setting up your SXA project, one of the next things you typically want to do is follow a myriad of guides to help finalize your setup.
One of these is to set up Security based on the SXA sites.
In order to do this, a number of the powershell scripts exist that are offered by the SXA product out of the box to help you set up the Tenant as well as the Site Security.

You can find all relevant information her:
https://doc.sitecore.net/sitecore_experience_accelerator/setting_up_and_configuring/setting_up/set_up_security_for_a_tenant_and_a_site

After you do this, I did however notice a problem...

We created a number of editors that had the 'Site author' and 'Site designer' roles.
However, the created users were not able to do all necessary actions immediately.

This user is now indeed able to log in and see and edit that SXA site.


First issue


But when we performed the following test:

Create a new page (Page type) > go into the Experience Editor > Add a (default) Promo block
At this moment the experience editor gives a popup that lets you create site content or content under the Data folder.
> We click the Create button next to the Data folder ...




And there we get a popup warning screen that says that this users does not have access to create that content...

This immediately felt like a problem in the SXA setup since I tested this on a vanilla SC9 and SXA 1.7.1 installation...

After some investigation and great support from the Sitecore SXA team they acknowledged this as a bug on their side and we found the following solution:

As a workaround for the issue, you can try the following steps:

1. Go to the item: /sitecore/system/Settings/Foundation/Experience Accelerator/Local Datasources/Virtual Page Data
2. Add the permission for the "Create" security right for all the needed users or role.  (In this case that is the SXA Author created role)

Publishing Issue

Just another thing to keep in mind is that with these rights, the editor is not able to perform any publishing. This might be by design for the users you just created.

If you do want to grant the publishing rights, then just assign the Sitecore Client Publishing role and they are good to go.

HOWEVER
If your intent is to take away publishing as a whole then there are some next steps.
As you will notice, the Publish section on the Ribbon is indeed as good as empty and no publishing is possible from there out.

However, right clicking on the Content Tree in Sitecore will still give you the option to publish. As well as the Publish button on the Experience Optimizer section in the Experience Editor that is still available...

Clicking this will however result in the following error:



So, actually apart from confusing the editors they are virtually unable to ever publish anything.

If you want to resolve this, make the following modifications to the security on the roles:

 1. Go to the Security Editor;
2. Select the sitecore\Sitecore Client Designing role;
3. Navigate to the  /sitecore/content/Applications/Content Editor/Context Menues/Default/Publish Item item.
4. Forbid rights inheritance as described in the below screenshot:



5. Select the sitecore\Sitecore Client Publishing role;
6. Allow the Read access explicitly as shown on the below screenshot:



7. After that, assign the sitecore\Sitecore Client Publishing  OR sitecore\Sitecore Client Advanced Publishing roles to your user.




There you go, you should be all set and ready to go :)