Pentaho Salesforce Foreign Key Loading

I was tasked with loading data into SalesForce from Pentaho.  There is a built in upsert command to do this, so it should be easy.  And for the most part it was, however, one issue that I came across is using external keys for linking objects in salesforce.  You can simply load values with the upsert, but if you are referencing another object by a key, it isn't straight forward or built well into the UI.  What needs to be done is almost an xslt type reference to the key of the other object.  

In my case, I had loaded all the accounts and needed to load orders.  The orders referenced the account by Account Number, which was a key on our custom account object in Sales Force.  After much trial and error, I was forced to do the following to tie the two together.


In the Module Field (Sales Force Field) I had to reference the object (Account) followed by a colon and then Acct_Number_C/Client_Account_R which the first half is the field on account and after the / is the field on the order object.  Once you do that, the objects are inserted and tied together correctly.

Enjoy!

Simple use of the JQuery TableSorter

I have had quite a few web pages recently that could use a little love in the display of large tables of data.  For one, we wanted paging and sorting of the columns.  This is a common problem, and the JQuery TableSorter makes easy work of doing this on your front end.  Here is what you need to do to make it work.

1. The first thing to do is include the correct JQuery files.  I did this using the Scripts.Render function in MVC.


@Scripts.Render("~/Scripts/jquery.js")
@Scripts.Render("~/Scripts/jquery.tablesorter.js")
@Scripts.Render("~/Scripts/jquery.tablesorter.pager.js")
2. Next, you must give the table containing your results a good name, I used tablesorter as the class name of the table to index from.

<table class="tablesorter" width="100%">

3. Next, make sure the header row is wrapped in a thead tag and each of the header row cells is a th, not a td.

4. Finally, after the table, put the following code in place.  Its a new div that will be the pager for paging and some javascript to set up the table and render it correctly.  I also added a section that does mouse over highlighting of rows since alternating row text isn't available through this technique, or at least that I could find.

<div id="pager">
        <form>
            <img src="@Url.Content("~/Content/images/first.png")" class="first" />
            <img src="@Url.Content("~/Content/images/prev.png")" class="prev" />
            <input type="text" class="pagedisplay" />
            <img src="@Url.Content("~/Content/images/next.png")" class="next" />
            <img src="@Url.Content("~/Content/images/last.png")" class="last" />
            <select class="pagesize">
                <option selected="selected" value="20">20</option>
                <option value="40">40</option>
                <option value="80">80</option>
                <option value="160">160</option>
            </select>
        </form>
    </div>
    </div>
<script type="text/javascript">
    $(function () {
        $("table.tablesorter").tablesorter({ widthFixed: true, sortList: [[0, 0]] })
        .tablesorterPager({ container: $("#pager"), size: $(".pagesize option:selected").val() });
    });
    $('td').mouseover(function () {
        $(this).siblings().css('background-color', '#EAD575');
        $(this).css('background-color', '#EAD575');
    });
    $('td').mouseleave(function () {
        $(this).siblings().css('background-color', '');
        $(this).css('background-color', '');
    });
</script>

How to Tag Classes To Determine Which to Reflect with MEF

So my last post covered loading classes dynamically from a directory in a plug-in fashion using MEF.  What I am going to talk about to day is how to customize that implementation to determine which plug-in to load.  This isn't a standard workflow with plug-ins, however it has its uses.  Generally with a plug-in, you load them all up and run the functions in each.  In my case, I have a database I am storing records to, and each record has a particular record type associated with it.  Depending on the record type, I want to load a particular plug-in to do processing. 
You may be thinking, this makes the client know about the plug-in's and makes them useless, however I in this case, I am creating records and assigning type at run time.  To assign type, I simply load the plug-in folder, and give the user a drop down list of the plug-ins to choose from then store the selection as a string in the database, so the client itself doesn't know about what plugins are there and adding a new plug-in will "just work" and dynamically load to the UI and can be used without any further configuration, so still holds true as a plug-in in my opinion.
The challenge with implementing this is to correlate the string with the class.  It would be easy enough to just use the class name, however that wouldn't be very user friendly.  Instead, I found the ExportMetadata tag to put on my classes.  Let's take a look.
[Export(typeof(ICalculationService))]
    [ExportMetadata("Identifier", "Add")]
    public class Addition : ICalculationService
    {
        public override int Calculate(int number1, int number2)
        {
            return number1 + number2;
        }
    }
As you can see, the class is the same as my previous post with the addition of the ExportMetadata tag which creates a name value pare.  I did string as my storage type.  Now I need to declare an interface for this metadata, the reason why will show up when we reflect it below.
[InheritedExport(typeof(ICalculationService))]
    public abstract class ICalculationService
    {
        public abstract int Calculate(int number1, int number2);
    }

    public interface ICalculationServiceData
    {
        string Identifier { get; }
    }
So there is the interface, rather simple.  It only includes the attribute Identifier which will map to the key in the key value pair created with the ExportMetadata.  Now time for the magic, how to get this info when MEF reflects the classes.
public class PluginRepository
    {
        [ImportMany(typeof(ICalculationService))]
        public IEnumerable<Lazy<ICalculationService, ICalculationServiceData>> CalculationServices { get; set; }

        public PluginRepository()
        {
            var catalog = new DirectoryCatalog(Environment.CurrentDirectory + "/Plugins/");
            var container = new CompositionContainer(catalog);
            container.ComposeParts(this);
        }
    }
That's my simple Plugin Repository class.  It looks in a passed in a Plugins directory under the current running directory and reflects out my ICalculationService objects into a Lazy object.  The lazy object has the ICalculationService object as well as the ICalculationServiceData object which contains my Metadata.  Now I can find my object in the array with the following simple Linq.  Very simple and relatively clean.
var obj = pluginRepository.CalculationServices.Where(c => c.Metadata.Identifier == "Addition").FirstOrDefault();
I haven't looked too much into the performance impact of reflecting all classes each time to load 1 for 1 function, however the Plugin Repository could be implemented as a singleton as to not allow the loading to happen more than once.  Content for another post.

How to Design your C# or .Net app with Plugins

So if your building out an app that is very extensible, you may experiment with Plugins.  Even if you simply have an interface with several implementations of it and don't want to use the giant switch block to determine which implementation to use, the plugin architecture can be useful to make much cleaner code that doesn't need updating each time you drop a new implementation of the interface in.  The switch block architecture is what I had used in most cases as most of my projects don't mature past the initial two implementations.  However, I have recently had a rash of tool creation that keep getting new features built in (very exciting) so am actually using my interfaces.  So now its time, to understand plugins.  
Google showed me there is a variety of ways to do this, none were the obvious answer, so let me walk you through each.
1. System.Addin route
The System.Addin route came about from Microsoft in .Net 4.0 about 2007 from what I can tell.  What it consists of is an implementation of the pipeline pattern between the application and plugins.  Its a very brittle approach to this problem, but does work and has a few advantages, mainly that versions between plugins and the host application can exist over a common contract.  http://msdn.microsoft.com/en-us/library/bb384200(v=vs.90).aspx shows the general overview of the libraries but this picture helps a lot.  

What it shows is the layers needed between the host and Add-in for this to work.  I will explain each.  The Host is your executable or app.  The host views are the abstract base classes you code your host to utilize.  The Contract is your interface.  On the Add-in side, you have the implementation (Add-in) which are implementations of the Add-in Views which are the same abstract base classes only put in a separate assembly over in the Add-in Side.  It has to be packaged separately and put in a different folder, yuck.  Adapters exist on each side that convert the Views to the contract on each end.
The power this gives us is you have the common interface in the middle and implementations on each end, so as long as your adapter is correct, you can version your views and implementations on each end all you want.  It feels very C++ like when implementing the Pipeline Pattern.  
The drawback is you have basically the same abstract class declared twice and a matching interface along with two adapters that are almost identical just to get that Add-in moved over.  That and the framework is built on a very rigid folder structure that must exist in the running directory or it won't work.  Its a lot of work in short.  The payday comes when you can access any unknown number of plugins with just this code.  A great walk through of setting this up can be found here.  http://blogs.microsoft.co.il/bursteg/2007/08/13/how-to-build-an-add-in-using-systemaddin/ 

string addinRoot = Environment.CurrentDirectory;
            AddInStore.Rebuild(addinRoot);
            var addins = AddInStore.FindAddIns(typeof(BaseAddInView), addinRoot);
            foreach (var token in addins)
            {
                var instance = token.Activate<BaseAddInView>(AddInSecurityLevel.FullTrust);
                Console.WriteLine(String.Format("Add-in {0} Version {1}", token.Name, token.Version));
                Console.WriteLine(instance.HelloWorld("Guy"));
            }
2. MEF
Homebased here https://mef.codeplex.com/ the Managed Extensibility Framework has a huge amount of flexibility to do most of your dependency injection needs.  It feels like the next generation of the Addin framework, all the features with much more ease of use.  For this, you need to include the System.ComponentModel.Composition assemblies and then just structure your code a bit differently.
What you do now is create your executable as you normally do with those assemblies included, and then create the interface for the object in question.  The interface will be tagged with the InheritedExport heading as you can see below.
using System.ComponentModel.Composition;

namespace SharedContracts
{
    [InheritedExport(typeof(ICalculationService))]
    public interface ICalculationService
    {
        int Calculate(int number1, int number2);
    }
}
This sets up this interface to be imported by unknown implementations later.  So let us put together one of those implementations in a new assembly.  The Interface should exist in its own assembly I should add so each plugin can reference it as can the host application.
using SharedContracts;

namespace AdditionService
{
    public class Addition : ICalculationService
    {
        public int Calculate(int number1, int number2)
        {
            return number1 + number2;
        }
    }
}
As you can see, the implementation of the concrete implementation of the interface is nothing special.  So now we need to tie it all together at run time.  To do this you need to import the plugins with the ImportMany tag in your class.  Since my test app uses a mainline, I created a very thin PluginRepository Class to represent this.
using System.Collections.Generic;
using System.ComponentModel.Composition;
using SharedContracts;

namespace SharedContracts
{
    public class PluginRepository
    {
        [ImportMany("ICalculationService")]
        public IEnumerable<ICalculationService> CalculationServices { get; set; }
    }

}
Now in my mainline, I can simply reference the directory the plugins will be in ("/Plugins/"), use my pluginRepository to fetch the plugins, and then iterate through them to show they are magically loaded and cast out with very little effort.  The MEF is truly very slick.
var catalog = new DirectoryCatalog(Environment.CurrentDirectory + "/Plugins/");
var container = new CompositionContainer(catalog);
var pluginRepository = new PluginRepository()
{
    CalculationServices = container.GetExportedValues<ICalculationService>()
};

foreach (var calculationService in pluginRepository.CalculationServices)
{
    const int number1 = 10;
    const int number2 = 20;
    int result = calculationService.Calculate(number1, number2);

    string output = string.Format("{3}.Calculate({0},{1}) = {2}", number1, number2, result, calculationService.GetType().Name);

    Console.WriteLine(output);
}
3. Reflection
In the end we can just use System.Reflection to do all of this and it really isn't much code.  Basically, all you must do is have a place to get your plug in assemblies (.dll) and then go through each and look at the types using the Assembly.LoadFrom function.  Once you have that you can use the Activator.CreateInstance function to get the type out and cast it to your interface and done.  

var files = Directory.GetFiles(Environment.CurrentDirectory + @"\Addins\","*.dll",SearchOption.AllDirectories);
            foreach (var f in files)
            {
                var a = Assembly.LoadFrom(f);
                var types = a.GetTypes();
                foreach (Type t in types)
                {
                    Console.WriteLine("Found Type: " + t.Name);
                    BaseAddInView ipd = (BaseAddInView)Activator.CreateInstance(t);
                    Console.WriteLine(ipd.HelloWorld("Heath"));
                }
            }
So you can do it easy enough on your own, and with the least amount of overhead really.  System.Reflection is all that is needed for this and there are no odd libraries to use to make it happen, though you may open yourself to security issues doing it this way.  I use AddInSecurityLevel.FullTrust which can be dangerous.  

Today, if you want to do a Plug-in Architecture, the MEF is probably the way to go.

Drop Down List for Enum or List in MVC C#

If you do a lot of MVC programming, you are representing objects in the database which many times have one to many relationships.  A great example of this is a type.  You may have a vendor with several types, like drop ship or mail order.  So in the UI, its nice to have a dropdownlist for the type vs. trying to key it correctly every time.  Here is my solution for this.  
First I create a function to load a list of objects I want the drop down list to represent.  Here is an example of a function that returns a list of vendors.

public static IList<IVendor> LoadVendors()
        {
            return Vendor.LoadList();
        }

After that, you add this to your view.

@Html.DropDownListFor(model=>model.VendorId, new SelectList(MyStore.DataBridge.LoadVendors(),"VendorId","Name").OrderBy(c=>c.Text))

You see, The Html.DropDownListFor will associate the value selected from the drop down list to the model.VendorId in this case so on post back reflection to the controller, this value will be reflected in the posted object, so that works great.   The other half is the list, what I found is you can reference any SelectList which I just new up and pass an IEnumerable (in this case the IList<Vendor> returned from my function> with the filed of the object you want to key on, and the field of the object you want to display in the ddl.  Perfect and simple.

To actually do this from a Enum, use the Enum.GetValues function.  It works slick.

@Html.DropDownListFor(model => model.FolderTypeId, new SelectList(Enum.GetValues(typeof(MyEnums.EFolderType))))