Thursday, October 12, 2017

Five Basic Things you should know before developing a Alchemy Plugin

Alchemy for Tridion is getting popularity by every day passing. More and more plugins are being submitted to Alchemy Web Store. I have developed few and it's really a fun. So if you want to give it a try go ahead, all you need to do is:

1. Install the Alchemy on your DEV CMS Machine.

2. Get the Alchemy development framework to visual studio using Nuget Package or VS Pack.

Now when you are all set to develop a Alchemy Plugin from your idea. Ask the below questions to yourself and note the answers:
  1. What does it do?
  2. What do you want to extend?
  3. Where to show your extension?
  4. When to show your extension?
  5. What resources you need to have in your extension?

What does it do?

The answer to this question will help you with
1. You can copy and paste the answer to the description element value of the "a4t.xml" file in your visual studio solution.
2. This will help you identify the possible conflicts with existing OOB GUI/Functionality. Which is quite important consideration before developing a plugin.

What do you want to extend?

So Tridion provides some extension points/areas OOB. In Alchemy Framework you would have all those extension points as Base Classes as below: 

  • CommandExtension
  • ContextMenuExtension
  • ExtendedAreaExtension
  • ExtensionGroup
  • RibbonToolbarExtension
  • TabPageExtension

You have to answer which extension point(or points), you want to extend. And based on this answer, you would create your Extension class by extending one of the above listed classes.

Where to show your extension?
So other than command extension, you need to tell Alchemy where you want to show the extension. This is really a important question as you need to make sure your extension doesn't break the existing GUI and not in conflict with another Plugin/Extension.

When to show your extension?
So there could be conditions when to show (or execute in case of command extension) the Extension. For example, a particular Extension could be available for any particular User Group. So if you have any condition like it, you would have to take care of this during the development. There are different ways to control it for different type of Extensions.

What resources you need to have in your extension?
You could have additional resources to support your extension like JS, CSS, ASPX ans ASCX files. You need to identify the resources and the place to put those. Alchemy Framework has a very specific structured way to organize those files.

I will cover all above points in detail in my coming blogs. I hope this high level information helps.    

Wednesday, September 27, 2017

Workflow, Core Service and Tridion Crashing Blues

The Tridion Workflow is basically used to audit the content before publishing out to specific environment. It is really a good module of Tridion CMS, little bit underestimated in my opinion though.

Recently, I come across a issue where Tridion was going unresponsive, when we had some 30+ workflow process ruining simultaneously. It took us some good time to figure out the root cause of the issue. My intention of writing this blog to save your investigation time in case you face the same issue.

The issue:
The Tridion gets unresponsive when there is load on the CMS server in the form of Workflow Processes.

The Root Cause:
While setting a Tridion CMS, one has to configure the Maximum Concurrent Core Service Instances allowed before Core Service Host gets throttled. If the number of Core Service Instances goes beyond that limit, the Core Service Host Service gets throttled and become unresponsive. In our case Workflow Processes were creating those Core Service Instances.

In our configuration settings, we had the value set at the default minimum value (which was 100); not the recommended value (100 x {No. of Cores}). So this minimum value 100 was getting crossed easily by the Core service Instances when the load was high and so Tridion was getting unresponsive.

These configuration settings are listed below and can be found in the files as under:

<serviceThrottling maxConcurrentSessions="100" maxConcurrentCalls="16" />

*The default value for the Maximum Concurrent Instances is { maxConcurrentSessions + maxConcurrentCalls}

1. {TridionDir}\webservices\web.config
2. {TridionDir}\bin\TcmServiceHost.exe.config

As per recommendation the default values should multiplied by no. of cores on the server.

Workflow Connection to the Issue:
When an auto External Activity in a workflow process starts, it automatically gets an instance of a “Ready Made” Core Service Client and it does not closed/disposed once the activity is finished (Proved) rather it is cleaned/closed when garbage collection happens later by the system (Yet to confirm with SDL). The more Workflow Processes result in more auto External Activities and so more concurrent Core Service Clients. Once the max allowed limit for Core Service instances is crossed, the CMS goes throttled and become unresponsive.

The Fix:
We had to increase the maximum allowed limit for load in configuration files on CMS. To do so, we increased the throttling attributes for Core Service to allow more concurrent Core Service instances as below (The configuration could be found in the files listed above already):

<serviceThrottling maxConcurrentSessions="100*{No. of Cores}" maxConcurrentCalls="16*{No. of Cores}" />

*Where {No. of Cores} is the number of cores available on the CMS Server.

I hope, this helps someone someday :)

Friday, June 2, 2017

Go To Location | Alchemy Plugin for SDL Web

At SDL Web Dev Summit 2017 in India, I got this opportunity to show & tell on "how to create a Alchemy Plugin in 30 mins". And I choose to build this simple "GoToLocation" Alchemy Plugin there.

This plugin adds a Ribbon Tool Bar Button 'Go To Location' to the Repository Local Items Views including Page, Component, Schema, Component Templates, Page Templates and Template Building Blocks. On clicking the button SDL Web redirects the user to the location of the item.

This plugin is useful in the situations when a user wants to navigate to the Item's location form the Item's View.

In case you missed the event, lets revisit the plugin again. So before we begin, get the plugin's code from here so that we both are on the same page.

Facts about the plugin:
  1. It is a Ribbon Toolbar Extension, which places a "Go To Location" button in the ribbon.
  2. It will be applicable to following views:
    • Component
    • Page
    • Schema
    • Page Templates
    • Component Templates
    • Template Building Blocks
  3. On clicking the button, a Command fires to take the control to the item's location.
  4. It needs to have following resources (Resource Group) available in Tridion
    • Image - to be applied on the button
    • CSS File - to define styling on the extension button
    • Command JS File - to define the command to be fired on button click

Lets visit the code against the above points:
  1. Open the file "Config\GoToLocationExtension.cs". you would notice that the class is extended with the base class "RibbonToolbarExtension". Doing this you instruct Alchemy Framework that your extension is a Ribbon Toolbar Extension.
  2. In the same file you would see the lines like Apply.ToView(Constants.Views.{ViewName}). The code is to apply the extension on different views.
  3. We always define the Tridion Commands in JS files and place it inside a fixed folder structure "Static/Commands". You can see we have "GotoLocationCommands.js" in there to define our command. In execute method of the command, we simply get the "GoTo" command defined in Anguilla Framework and execute it on selected item.
  4. Resources are generally supportive files needed in Tridion for your extension. These files are organized in a fixed structure in the project inside the "Static" folder.
    • Image: To apply an image, we need to add the image in the project inside the folder "Static/Images" so that it is available to use.
    • CSS File: This file contains all the styling we need to add to our extension and sits in "Static/Styles" folder. In this case we just want a background image for the ribbon bar button as styling. If you notice in the css file, we are applying the image on a element with the id "RibbonToolbarGoToLocationButton". The id is nothing but the Assign Id of the extension (defined in "GoToLocationExtension.cs" file), which ends up as a HTML element id for the extension. 
    • Command JS File:  The file is located at "Static/Commands" and contains the command as we mentioned in point 3.
Now when we created different pieces we need for the functioning of our extension, We need to instruct Alchemy Framework; what is what and how these are inter connected?
  1. Alchemy Framework needs to know about the commands your extension have and to define it, we create a class derived from "CommandSet" base class. The class "GoToLocationExtension.cs" could be spotted under "Config" folder, having the command added (defined in the Command JS File, the name must match)
  2. We must tell Alchemy, which resources are going to use for the extension and to define it, we create another class derived from "ResourceGroup" base class. This class adds all the Resource Files, Command Sets and other dependencies needed for the extension. The class can be found at "Config/GoToLocationResouceGroup.cs".
  3. Lastly tell Alchemy that the extension is dependent on the Resource Group we just created. To do so, add the line Dependencies.Add<GoToLocationResouceGroup>() to the extension class "Config\GoToLocationExtension.cs".
And that's it. All other properties in the code files are quite self explanatory. 
Now build the project, you get your .A4T alchemy file for the extension. yay!

Monday, December 26, 2016

Edit Templates From Page | Alchemy Plugin

SDL Developers India Community organized a professionals meet this year in New Delhi and I was fortunate to join the event. I met some really nice guys from the community there and had a good time. I also spoke on Alchemy along with Robert Curtelle and after finishing the session, this guy Tejas came to me with this idea of the plugin.

He said, as a Tridion developer when he found a rendering bug on a webpage (published from SDL WEB), he used to do the following:
1. Navigate to the page in Tridion.
2. See which templates were used.
3. Memorize the Name or TcmId of the template.
4. Navigate to the template to open it.
5. Check the TBBs used in the template to identify/fix the issue.

He asked me it would be really helpful, if we could build a plugin which gives links/buttons to Edit the templates directly from the page. With this we could eliminate the steps 2, 3, 4 from the process above. I really liked the Idea and almost after a year I manged to build the plugin (Yeah, I know I am lazy :) )

What it does?:

Well, it is one of the simplest plugins you would have. It simply places edit buttons in form of the templates used on the page. User can simply click the buttons to Open/Edit the template.
Page Template Edit Button

Let's build it once again:

I've already shared the code for the plugin on GitHub. You can have a look at the code in detail after downloading it but let's discuss it briefly here.
In technical terms, we want to build a "ExtensionGroup" GUI Extension using Alchemy, which has group of resource files, to be targeted to the Page View ("Tridion.Web.UI.Editors.CME.Views.Page").
So after creating a project using the A4T template in Visual Studio, I created two classes:

1. EditTemplatesFromPageResourceGroup (Extending from ResourceGroup base class)

2. EditTemplatesFromPageExtensionGroup (Extending from ExtensionGroup base class)


As the comment inside the code says, this code simply adds "EditTemplatesFromPageResourceGroup" Resource Group as an Extension to extend the resource "Tridion.Web.UI.Editors.CME.Views.Page". That means all the resource files referenced in the class "EditTemplatesFromPageResourceGroup" will be available on the Page.


This class represents a Resource Group, we want to add for the extension.
From line 17 to 19 we are adding JS and CSS files needed.
Line 21 adds a Web API Proxy in case we want to interact with CMS using Web API Controller, Though we are not using it in this version but added it for future versions.
Line 23 adds JQuery as a dependency. With this we can have JQuery  available in our JS files. If you look at the JS code, you will see we are creating JQuery object something like

$JQ = Alchemy.library("jQuery");

Okay, lets talk about the resource files used in the Resource Group . It has the following resource files:

1. PageTemplateEditLink.js
  This JS file is responsible to render the Page Template Edit Button. If you look at the code, it simply
  1. Create a HTML Element for the button
  2. Insert it beside the Page Template dropdown
  3. Add a "click" event handler function to the button, which runs the following JS code
var pageTemplateId = page.getPageTemplateId();
var s = new Tridion.Cme.Selection();
$commands.executeCommand("Open", s);

The code gets the current Page Template from the Page object and fires a "Open" command on it using Anguilla framework.

2. ComponentTemplateEditLink.js
This JS file is responsible to render the Component Template Edit Button/s. What is does:
  1. Create a HTML Element for the button
  2. Insert it beside the Component Template dropdown in Component Presentations Tab
  3. Add a "click" event handler method to the button as below
// Get the selected Component template from the dropdown anguilla object
var ctId = ddl.getValue();
// Execute the open command
var s = new Tridion.Cme.Selection();
$commands.executeCommand("Open", s);

The code gets the current Component Template from the dropdown object and fires a "Open" command on it using Anguilla framework.

3. EditTemplatesFromPage.css
This file contains all the css styles used for the Edit Buttons.

After updating a4t.xml file with the name and description, now we are all set to build our plugin and after a successful build we will get the magic A4T file, which can be installed to Tridion SDL Web.

Again, I have shared the plugin code on GitHub you can download it if you want. In case you have any questions, feel free to contact or write comments. 

Friday, October 21, 2016

Forcing Workflow on the Components | Things you should know

We implemented workflow using bundles with Tridion version 2013 SP1 HR1. Customer really liked the overall functionality but when a component updated outside of the workflow or a new component created, component was set to approval status 'undefined'. With this 'undefined' approval status there was no restriction on publishing those components at all, means the content which was yet to be approved by workflow process could be published. Certainly we didn't want this as this takes away one of the main purposes 'Content Auditing' of having the workflow.

So we needed some way to mitigate this risk and force the workflow on the items before they are set to publish.

Tridion provides a OOB option to force workflow on items, for this use the checkbox “Any changes made to a Component based on this Schema require approval by a Bundle Workflow Process” in the Component Schema as shown below:

enter image description here

How does it work in concept 

If the check box is checked in the schema, components based on the Schema cannot be checked-in except by workflow. The process would be, you add the items to a Bundle and when you are ready for all of the items inside to go through workflow then Start Workflow on that Bundle.
If someone updates/creates components outside of workflow, Instead of being checked-in, the components will be "Waiting for Workflow" before you add it to a Bundle and start the workflow on it. Components could be unlocked, so other people can continue editing it, with the condition that they need to take over all previous changes too (so if they Undo Checkout, they throw away all changes, not just their own). The CME and Experience Manager will prompt you to "take ownership" when you attempt to edit such a component, The workflow doesn’t give that prompt and assign the previous changes to the current user of the activity.

Porting content using Content Porter tool:

The content porting remains the same in principal with this workflow enforcement, below are few points worth highlighting:
a. Components could be updated/created outside of workflow for the first time, a  minor version will be created with the updates and then components will be locked and waiting for workflow. (Further updates to the components are possible manually but not with the content porter. In manual case user will have to “Take Ownership” of the previous updates).

b. Subsequent updates could only be made If the components are in workflow, the workflow activity is assigned to the user doing the porting. OR once the items have gone through the workflow (components have latest major versions).


We are supporting translation inside workflow and we faced a issue related to translation after enabling the workflow enforcement as asked here.

So we had a “Send For Translation” workflow activity to send the content for translation. This activity creates a translation job of type “Push” and sends components for translation. when the translation job is sent, the component is localized and checked-out in target publications. When the translation is retrieved by the translation management system it's checked back in. (This works like this when we don't force the workflow in the components).
But after forcing Bundle Workflow Process on Components using the checkbox in the schema, Once translation is complete, the components are NOT localized with the local content in the target publication.

I guess, this could be because when TMS tries to localize and update the component, it can’t because Tridion expects the component to be locked by a “Bundle Workflow Process”. And so the component is not localized and remains untranslated.

This issue is with 2013 sp1 and as it mentioned in one of the answers, there is a a hotfix for this issue "TT88491".
But there are workaround for this issue without this hotfix.
  1. Localize the schema at local publication level and uncheck the checkbox.
  2. Disable workflow for local Publication.
I've not tested it but expert says that this issue is fixed in web 8.

That's it chaps, it's really a cool feature do try it.

Friday, September 23, 2016

Items Panel Search Alchemy Plugin

Here is another Alchemy plugin called Items Panel Search, which is now available on Alchemy Web Store. It is inspired by another plugin called Publication Panel Search, publication panel search plugin operates on publications list but this plugin on items list in the right panel. It places a search box over items list to search or filter items. User types some text and the items list gets filtered on every key press and shows the items containing the string.

Also, the plugin preserves the search value and the search results if user open an item from the list or does the sorting. User can reset the search by clicking the refresh button at the top of the list.

Other than search for a particular item in a long item list, this plugin could be useful in situations when someone wants to operate on a set of items having a common string in title of the items. As shown in below image, all the items having “Articles” in titles are filtered.

This plugin gives users two search options, titles only and all information presented in the list. By default it searches on the titles of the items, if user want to search for all information shown, he can enable it going to plugin configuration and set the value for “SearchAllInformation” to true.

In technical term it is a GUI extension of type Resource Extension Group added to the Dashboard View. It simply contains a JS file as a resource, that is responsible to put the search box on the top of FilteredListControl and all the functionality included.

To see the plugin code please visit this Github link.

Feel free to contact if you have any questions or suggestions regarding this plugin.

Sunday, May 29, 2016

Title Translator | Alchemy Plugin for Tridion

I worked on a Tridion implementation for a client managing huge local content for their websites. One could imagine that local content is hardly anything to do with a developer, but he could be wrong. So at that client, with the content inside the localized components, the title of the items were also in local languages (at many places), specifically they had tons of local taxonomies with the local language titles. Now if any issues reported for a localized website, it was a nightmare for the developers to dig in to the content while investigating that issue because we developers knew only English language.

Few weeks ago, while looking at some of old work for that client that I remembered those days and that issue. So I decided to create a Alchemy Plugin called called Title Translator to address that issue, you can follow the link to Alchemy Web Store and download it from there.
This is really a simple plugin which uses SDL Translation API in background, all you need to do is get a SDL Translation API key, set the key in Plugin Configuration and you are ready to go. In the coming versions, I will try to include the support for Microsoft and Google translation as well.

To use the plugin, simply right click on a title in your CMS Filtered Item list or left-hand​ navigation panel and select 'Translate Title'. The updated title will show in the notification bar.

On the Technical side, This plugin is created using Alchemy Framework. The idea was pretty simple, create a context menu extension and on clicking it fire a command to show the translated title in notification bar.

The Code for the Plugin can be found here on Github. This basically have following building blocks:

  • TranslatorContextMenuExtension: This class holds information about your context menu extension. Other than specifying name and id, below are the important pieces of info it has:  
    • The order of your extension in the context menu.
    • Associated command to the context menu extension.
    • Dependent resource groups.
    • Which view, the extension applies to, In this extesnsion it applies to "DashboardView".
  • TranslatorCommandSet: The class is all about creating a command set from the commands specified in the JS files. We have only one command called "translate" and it is add to the commandset.
  • TranslatorResourceGroup: This class is used to tell alchemy, which resources (files/CommandSets) are you using in your extension. We have just one JS file named "TranslatorCommand.js" and one command set, so adding those in there.
  • TranslatorCommand.js file: This file holds the command code, which fires once "Translate Title" in context menu is clicked. The code basically sends the request to the SDL Machine Translation Service and gets back the translated title as an response and shows it in notification bar.
That's it chaps, go use it. And yeah, feel free to leave comments, questions, report bugs, improvements, pretty much anything related to it.