Documenting SalesLogix Web with Reflector

If you have been working with SalesLogix 7.2 Web, you’ve probably discovered the lack of documentation and ran into several frustrating and painful moments where you were not quite sure how to accomplish what you needed. I’ll let you in on a secret. You have all the documentation you need – well, maybe not all you need, but you do have a lot.

The platform that SalesLogix Web is built on is comprised of many .NET assemblies. Thankfully, the Sage development team decided to not obfuscate these assmeblies. As a developer for SalesLogix Web, I find that I can find all the documentation I need using Lutz Roeder’s Reflector. For those who might not know, Reflector is a tool that allows you to dig into a .NET assembly. Not just to see the namespaces, classes, and methods contained in the assembly, but Reflector will also interpret the IL code in the assembly as C# or VB.NET code – so you actually get to see the code inside the assembly as well.

When working with SalesLogix Web, and especially when troubleshooting a problem, I find using Reflector and invaluable part of the process. I keep it open all the time when working with SalesLogix. Here’s an example of something useful. I had a customer that could not create tickets for certain accounts. When the form was launched to create a ticket a runtime error would be thrown. So, what do you do about that? Here’s what I did. I fired up Reflector and started digging (after loading the site in Visual Studio and stepping around a bit – but that is another post). The best place to look is in the OOTB business rules. Open up Reflector and add the “Sage.SalesLogix.BusinessRules.dll” assembly. I ended up in “Sage.SalesLogix.Ticket” namespace and then the “Rules” class. The cause of my problem was found in the GetPrimaryContact method. In Reflector I can double click this method and see the C# code in this method. It looks like this:

private static IContact GetPrimaryContact(IAccount account)
{
    if (account != null)
    {
        foreach (IContact contact in account.Contacts)
        {
            if (contact.IsPrimary.Value)
            {
                return contact;
            }
        }
    }
    return null;
}

 

After looking at the code, I can see what the problem is. The IsPrimary property on the Contact is a bool? (a nullable bool). This code is assuming it has a value without first checking (it should read if (contact.IsPrimary.HasValue && contact.IsPrimary.Value) to account for nulls). From that I can guess that the account’s that this problem is happening on do not has a contact with a null value for IsPrimary. This is something I could not have determined if I didn’t peek inside the business rules assembly to see what the code looked like.

Here’s another example. Let’s say you want to automatically attach a contact process to a contact. Some looking around at the ScheduleProcess method in the Sage.SalesLogix.Contact namespace shows you just how to do that:

    DateTime utcNow = DateTime.UtcNow;

    IProcess item = EntityFactory.Create();
    item.BasedOn = pluginId;
    item.Contact = contact;
    item.Family = family;
    item.LastAction = new DateTime?(utcNow);
    item.Name = name;
    item.NextAction = new DateTime?(utcNow);
    item.Node = "@PROCSTART";
    item.StartDate = new DateTime?(utcNow);
    item.StartUser = item.User;
    item.Status = 2;
    item.Suspended = 0;
    item.TargetName = string.Format("{0}, {1}", contact.LastName, contact.FirstName);
    item.User = owner;
    contact.Processes.Add(item);
    PluginBlob blob = PluginBlob.LoadById(pluginId);
    item.Data = blob.Data;
    item.Save();

 

That is just one of many examples of how you can learn how to use the entity model and platform API to do things for SalesLogix Web. Here’s another. Say you wanted to get a list of attachments for an account? I can dig into the GetAttachmentsFor method in the Attachments business rule:

return EntityFactory.GetRepository<IAttachment>().FindByProperty("AccountId", entityID);

 

This goes way beyond business rules. Let’s say I am writing some code to manipulate a QuickForm control, such as a Grid, in a LoadAction. I can open up “Sage.SalesLogix.Web.Controls.dll“ and look at the properties for the SalesLogix Grid control and will find, in addition to all it’s built in goodness, that it inherits from the ASP.NET GridView control. I know how to work with a GridView, so that opens up a whole lot about what I already know about the SalesLogix Grid control because of it’s supertype. I can dig through the available services and just about everything that makes up the SalesLogix Web platform. That’s just cool – a big huzzah for the Sage development team for not obfuscating – we got some documentation and they didn’t have to do anything at all 🙂

While I would love to have actual documentation for the new SalesLogix Web platform, but at least Reflector gives me the next best thing. I couldn’t imagine working with SalesLogix without it.

ABOUT THE AUTHOR

Ryan Farley

Ryan Farley is the Director of Development for Customer FX and creator of slxdeveloper.com. He's been blogging regularly about SalesLogix, now Infor CRM, since 2001 and believes in sharing with the community. His new passion for CRM is Creatio, formerly bpm'online. He loves C#, Javascript, web development, open source, and Linux. He also loves his hobby as an amateur filmmaker.

1 Comment

  1. Hi Ryan Farley,
    It’s Very good for beginners, if any one have tutorials or any document for learning

    Thanks
    Shiju 🙂

    Reply

Submit a Comment

Your email address will not be published. Required fields are marked *

Subscribe To Our Newsletter

Join our mailing list to receive the latest Infor CRM (Saleslogix) and Creatio (bpm'online) news and product updates!

You have Successfully Subscribed!