sitecorestorm: 2016

Tuesday, December 13, 2016

Why The Sitecore Data Exchange Framework is Important

I recently had a discussion with a colleague around how we were best going to integrate a CRM and multiple external data lookup services with Sitecore Xdb for a full experience management merry go round.

The issue was a bit of a brain melter because the CRM is in transition between platforms, the external service lookups need to run through Azure Apps and the whole back end system is undergoing alignment to get a single view of the customer internally - fun fun fun.

So you can see that there is a lot of integration pieces that need to be created and managed in an orderly modular Helix-compliant fashion.

Now initially the integration pieces (CRM of any type - might as well be a black box) and numerous external lookup services (writing to the xDB too) might be small to middle sized but undoubtedly they will get added to and hopefully not in way that adds technical debt - that would be my preference.

To my mind a lot of these processes can be built abstracted and modular and seem well suited to being implemented using Pipelines in the Data Exchange Framework.

So why, I asked myself, add another layer to this bucket brigade?

Well being only a junior dev in terms C# experience, I can see we have come along way with MVC and NuGet and other methods to keep our code modularised and re-usable etc. etc., but the Data Exchange Framework offers something that no well structured solution can.. and that is..

The ability to model and organise processes as an ETL (extract, transform and load) layer for Sitecore. The parts of a synchronization process map directly to ETL functions.

The Data Exchange Framework (DEF) allows you to model the ETL functions using Sitecore Items in the content tree and this is where it's classic Sitecore.

DEF also does other funky stuff, your Pipelines can be run on other machines with Sitecore acying as just a configuration server.

Lastly DEF is the precursor to xConnect (as I understand it), the coming integration framework for Sitecore. As such I assume it will be the Sitecore recommended approach to external integration going forward so it seems like a good plan to get on board now.

The developers guide is a good place to start:

http://integrationsdn.sitecore.net/DataExchangeFramework/v1.2/

And the full API is available here:

https://dev.sitecore.net/~/media/D47877D168AE446CA05500F24AF7D9C1.ashx

Main Sitecore page and download here:

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

Thursday, October 20, 2016

Token Fun With PXM

If you've had any experience with Sitecore Print Experience Manager you'll probably know what powerful features it brings to the world of integration between print and Sitecore.

If not you can get a good overview here:

https://community.sitecore.net/technical_blogs/b/getting_started_with_sitecore_print_experience_manager/posts/getting-started-with-pxm

Recently a customer asked for what I would expect to be a reasonable feature, but first a little background.

When you create a PXM project (aside from the master document step) you effectively create objects or elements using InDesign in your document, for example a text frame that can populated by either Sitecore content or user entered content via the Document Publisher. This element is them saved back to Sitecore as a snippet, effectively a Sitecore item in a standard hierarchy.

But what happens if the document you are usng has the same pieces of text in multiple places, i.e. company name. In a standard PXM set up, you would have this field repeated numerous times and be forcing the person creating the document to type the same text in multiple times.

Behold the brilliant customisations available via the SPEAK interface and a simple but powerful solution from a developer working for the customer, and yes it does use tokens and yes there is curly brackets involved (steady!!)

The simple solution was to include curly bracketed tokens in the actual InDesign template itself, i.e. {company name}.

And then using the framework already provided, simply add a button to the edit screen in the Document Publisher that calls a spot of code that parses the template for curly bracket wrapped values and present them in a modal dialogue, enter your values, click update and the values are written back into the document, replacing the original curly barketed ones.

Click Preview again and voila, there's your document with every instance of company name (for example) replaced with your (entered once) value.

This approach gets around some tricky issues with text flow etc. and also doent need anthing tricky and somewhat obscure like InDesign variables.

One another note two quick solutions for hiding Document Publisher fields you dont want the user to see:

For a text snippet for example, create a new template that inherits from the original element and assign it to the snippet, Document Publisher wont pick it up but it will appear in the document preview and final render.

OR just use security permissions on the element itself.

Have yourself a whole heap of PXM fun and thanks for reading.

Tuesday, September 20, 2016

Sitecore Experience Accelerator (SXA) - Installation Tips

If you are like me you will be keen to run up the new Sitecore Experience Accelerator. For those of you that haven't heard of it, it's a brand new development accelerator kit from Sitecore that adheres to the Helix principles, read an overview of the Helix principles here from Ryan Bailey.

Sitecore describe SXA thus:

"Web development teams use Sitecore Experience Accelerator (SXA) to speed up the production of websites and to reuse components, layouts, and templates across a variety of sites. SXA separates structure from design, so front-end designers, creative designers, content authors, and developers can work in parallel and you can deploy and maintain multiple sites quickly and cost effectively. Once a basic user experience plan is in place, everyone can get started on the platform. For example: the content author can start entering the content in the wireframe environment, while the front-end developer works on the theme, and the developer sets up the data templates."

You can read all about it on the Sitecore documentation site.

If you are keen to install it and have a play there is a few things to note:

It requires Sitecore Powershell extensions and they need to be specific to the Sitecore version you are installing:

Before installing SXA, ensure that you have the following:

Sitecore Experience Platform 8.2 initial release or
Sitecore Experience Platform 8.1 Update-3
Sitecore PowerShell extensions for Sitecore XP 8.1 – full 4.0 or
later for Sitecore XP 8.2 – full 4.1 or later

You can grab them here on marketplace.sitecore.net

The next things to note are

Make sure you restart the Sitecore Client AND Server after installation
Make sure you go to Control panel and rebuild all search indexes.

You will need to change the layout on the homepage to one of the SXA layouts to start your fun.

Important

Lastly SXA requires a license update, even if you are a partner you will need to get an updated licence to include SXA otherwise you will encounter this:

Have fun and I will be posting more tips and tricks as I explore more.

Monday, August 22, 2016

Rich Text Editor Drop-down Classes in Sitecore 8

The Rich Text Editor in Sitecore is remarkably flexible in terms of customising to make life easier for our editors. Part of this is adding classes to the Apply CSS Class drop-down, here you can define classes to match your corporate branding and hopefully reduce the temptation for editors to go mad in the HTML tab, (or even allowing you hide the HTML tab entirely (core database - security permissions)).

This blog was inspired by sifting through several posts to find out how adding these classes is different in Sitecore 8 >

The community of course is always a good starting place and this post does in the end provide the answer.

https://community.sitecore.net/developers/f/8/t/2114

I did however think it deserved a simple summary so here we go.

Steps

The old way

Add you classes to your main CSS, these days we mostly include a SCSS (SASS) file as compiled CSS is modular and much easier to work with than on huge file
Add you CSS to your editor file, this file is used to display your edits in the RTE editor window and keeping it in sync with your front end CSS help avoiding editor confusion

How this editor file is defined and included will differ depending on your solution.

The default Sitecore install uses a web.config setting:

<setting name="WebStylesheet" value="/css/yourstylesheet.css" />

Note: I'm writing this based on a Habitat solution so with everything Habitat the web.config is broken out in many separate .config files. The base solution includes a theming.config shown below:

<mvc.getPageRendering>

</defaultAssets>

</processor>

</mvc.getPageRendering>

</pipelines>

<patch:attribute name="value" value="false" />

</setting>

</settings>

</sitecore>

</configuration>

The style-sheet that is defined there will be used to populate the drop-down and used in the RTE. The gotcha with this is that everything in this style-sheet will be shown in the drop-down, using the class name which are often not descriptive or understandable. Things like anchor attributes will also be shown which is just messy and confusing for editors.

The better solution is used in Sitecore 8 and uses 3 files

The new way

yourMain.css
yourEditor.css
ToolsFile.xml

ToolsFile.xml is found here:

\inetpub\wwwroot\sitecore\Website\sitecore\shell\Controls\Rich Text Editor\ToolsFile.xml

This xml file defines the tools in the RTE and one of the nodes is <classes> which defines the classes in the drop-down. Here you can define a friendly name for your classes and point it to the corresponding CSS class using the value attribute.

i.e. <class name="Green Button" value=".green-button" />

Get these three ducks in a row and your good to go.

Don't forget to clear your cache after making changes, some browsers may be reluctant to show your changes.

As an aside the ToolsFile.xml also allows you to define the HTML snippets and custom links in the RTE, again useful for making the job easier for your editors and avoid them pushing presentation language tasks back to the dev team.

Hope this is useful for someone.

UPDATE

The order that the classes are shown in the

yourEditor.css

file, determines the order they will appear in the drop down, not the order that they are defined in

ToolsFile.xml

Tuesday, May 24, 2016

I was asked to help out another Sitecore partner with my experiences using Sitecore Print Experience Manager. Being this is my first blog, its a little bit all over the show, but will hopefully help out other users implementing PXM

https://doc.sitecore.net/print_experience_manager

I have outlined some of our experiences below. We are using:

· Sitecore 8.1 Update 1
· PXM 8.0 Update 1

https://dev.sitecore.net/Downloads/Sitecore_Print_Experience_Manager/8_0/PXM_80_U1.aspx

· InDesign Server 2015
· InDesign 2015
· InDesign Connector x64 CC 2014
· ODG 8.0 rev. 150128
· InDesign Server Engine 2014 - https://dev.sitecore.net/Downloads/Sitecore_Print_Experience_Manager/8_0/Sitecore_Print_Experience_Manager_for_8_0.aspx#
· Dashboard Service x86
· InDesign Server Processing Service x86
· Microsoft Message Que
https://msdn.microsoft.com/en-us/library/ms711472(v=vs.85).aspx
· Windows Server 2012 R2
· On-premise Mongo replica set with authentication and SSL
· Standard set up with 1 CM, 2 CD, 1 dedicated InDesign Server

If you are using Sitecore 8.1 and ODG you’ll need to get the fix Sitecore support put together to fix issue with the SPEAK interface for the ODG, SPEAK was made over in 8.1 so some SPEAK modules will have issues.

Overview

PXM is a very cool bit of kit, essentially creating a simple doc starts with InDesign which has the Sitecore connector installed and configured to connect to your management server.

An InDesign document is actually just an XML doc so this is very well suited to being stored in Sitecore, the standard hierarchical construct is recreated in Sitecore with (loosely) a Doc>Page>Snippet tree structure.

Snippets can be related to a single element on a page such as a text field, image field, Sitecore field.

Takeaway here: Since an InDesign doc is stored as Sitecore content, all Sitecore functionality (Workflows, security, API etc.) can be leveraged over what is essentially print content, let that one sink in!

Installation

We followed the Sitecore doc for installation, but were also helped a lot by Mark Demeny’s video series on PXM

https://www.youtube.com/playlist?list=PL1jJVFm_lGnyq030ylG0YOM3S9OvdNbN0

Wiring it all up is …. Easy when you have done it 10 times, complex the first time.

Things to watch out for

Overview

In a multi-server set up the publish process goes a little like this: (Simplified)

· Using a web service, Sitecore sends an INDD and XML file to a Publishing Cache folder on the InDesign Server (IDS) and calls the IDS service to process it.
· The IDS takes the INDD file and using the instructions in the XML file, creates the specified PDF and places it back on the management server in a folder that has been mapped as a virtual drive in the web root.
It then sends an email notification to the user with a link to the pdf, voila download.

· So the Publishing cache on the IDS needs to be network accessible with permission for NETWORK SERVICE read / write

· The publishing folder also needs to be the same so IDS can deliver the finished doc.

If you aren’t getting the full cycle working, permissions is a good place to look.

Also note if you set the PublishFolder up as a share, you need to put this into the Print Studio settings as the share name (\\) so when this information is passed to IDS it can look back at the CM and find the correct folder to publish to.

Config:

In a three server set up the installed services / modules looks like this:

· PXM – core module – App_Config>Includes>PXM>Sitecore.Print.Studio.config - These is also config in the content tree Print Studio> App Settings>Publish Paths

· ODG - App_Config>Includes>PXM>Sitecore.ODG.config

· Dashboard Server - Installs into Program Files (x86)>Sitecore Config in program folder

· InDesign Service - Installs into Program Files (x86)>Sitecore Config in program folder

· MMSQ – Set up through Server Manager

IDS

· IDS (IDS has its own InDesign Server Service, configured through an app in Program Files>Adobe>InDesign), this allows you to specify the port (potential issue the 64 bit version is not registered so you cant create the service, fix is in Mark Demeny’s video (https://www.youtube.com/watch?v=9Ir_aOAgukk&list=PL1jJVFm_lGnyq030ylG0YOM3S9OvdNbN0&index=5)
· InDesign Server Engine 2014 – this is an IDS plugin by Sitecore for IDS
· MMSQ

Make sure that the following is set up and matches across all configs:

· IDS Address and port number
· Microsoft Message que name
· Adobe application name
· Paths to logfiles

Again Mark Demeny’s video series highlight potential pitfalls around config.

Test by calling the respective web services on both the IDS and CM through a browser, instruction in the videos

My best friend in setting this up the first time was log files>

· Sitecore – Print.studio.log (through the usual log viewer)
· Log files for the dashboard service and InDesign processing service in your PxmPublishing subfolders.
· Log files on the IDS server

Creating a Simple PXM Project

· Grab your InDesign doc and open it in InDesign
· Create a new master document under Master Documents in the Sitecore >Libraries Window – this is a little fiddly if you aren’t an InDesign native, thanks Google. Master docs can also contain embedded elements that will be used on all page in a PXM project, (note that Master page elements can be overridden on individual pages in InDesign).

· Save it back to Sitecore – this will be saved in the Media Library as an INDD file, this essentially grabs the page layout, dimensions and styles (important for creating your brochure later)

· Next create a new project and drag it to the project tab to start editing and adding pages and elements. You have the option to save content and content and layout for individual pages or saving all pages by choosing the root page element (from memory). To include Sitecore content (really the big advantage for PXM), you’ll need to make sure Print Studio is configured in the content tree under one of the settings node (sorry away from the site today or I’d be more accurate and include screenshots) to point to your starting content node. Then in InDesign , on the Content tab you can browse to a content item, and drag and drop individual fields to your InDesign doc and save them back as snippets.

· On save the PXM project is created under the Print Studio>Projects folder and you can also tweak nodes, styles etc. here too.

That’s it once over very lightly, areas where you may wish to customise:

· SPEAK interface
· Custom field renderers (for example to do look ups based on Sitecore field values or create a table of contents from a Content node construct)

At this stage we are only using the ODG to allow sales staff to create customised PDF’s using Sitecore content through the Document Publisher. This is done on the CM so we haven’t had to fool around with the CDs just yet, but assuming connectivity is all good shouldn’t be a problem.

SDN has a basic project to get you rolling here:

https://sdn.sitecore.net/Products/Adaptive%20Print%20Studio/APS%201,-d-,2/Adaptive%20Print%20Studio%20Solution%20Cases/Creating%20a%20JetStream%20Brochure.aspx

As far as InDesign goes, my golden rule is garbage in, garbage out, make sure your INDD doc is clean of spurious elements such as path generated elements – you can just cut n paste an existing INDD doc in, but I have had better success creating it element at a time to avoid adding unnecessary snippets to the project.

(Tip: If you need to hide snippet elements in the ODG, create a new template inheriting from snippet and apply to hide snippets, the ODG work on GUID so they won’t be shown but will still get published)

Disclaimer: I wrote this blog from memory without actually sitting in front of the environments, so path / file / content node names may vary slightly.

Disclaimer 2: If I have anything fundamentally wrong, feel free to comment, Sitecore is all about continuous learning.

Thanks for reading