CRM Developer

Public SalesLogix Developer Classes Revamped

Ryan Farley — Mon, 27 Oct 2008 23:51:00 GMT

I announced a while ago that we will be offering some public developer training classes for SalesLogix Web. We will be making some changes to the class outline I posted earlier.

The new classes we will be offering will be as follows:

Building Solutions for SalesLogix Web
This is the all-inclusive web developer class that uses the concept of building a complete solution to train around. We will go from start to finish in building a solution that covers all typical development scenarios when developing for SalesLogix Web.
Process Orchestration
This is a full class that will focus on working with and developing for process orchestration (Windows Workflow) with SalesLogix 7.5 (Web or LAN).
SData & Integration
This class will focus on building solutions using the SalesLogix SData & REST services layer for both reading SalesLogix data and writing to SalesLogix (creating new records, updating, & deleting), focusing on integration and external application scenarios.
SalesLogix .NET Extensions
This class will focus on developing .NET Extensions for the SalesLogix v7 and higher LAN client. We will take an in-depth look at building, debugging, & managing .NET Extensions as well as look at cases when to use .NET Extensions vs. standard SalesLogix customizations.
Beginning C# & .NET Development for SalesLogix
We are also considering a "Beginning C# for SalesLogix" class that will cover the basics of C# and the .NET Framework from the perspective of working with SalesLogix.

I will be posting the complete class outlines and schedules to this site & RSS feed shortly. Stay tuned.

SalesLogix Group Explorer Added to Labs

Ryan Farley — Sat, 13 Sep 2008 08:06:00 GMT

I added a new utility to the Customer FX Labs tonight, the SalesLogix Group Explorer. This utility allows you to dig deeper into the definition of SalesLogix groups than you ever thought possible. You can see the group's layout, included columns, conditions, sort order, and way more. Not only that, but you can also see the SQL query behind the group and view the data that makes up the group, all from outside of SalesLogix. The Group Explorer also gives you the ability to quickly export group data, exporting 100,000 records in a fraction of a second.

Take a look at the SalesLogix Group Explorer (more images in the Labs page):

(click for larger view)

The Group Explorer is currently in beta, but a free utility and downloadable in the labs. I've only tested this on versions 7.2 and higher so far (might or might not work with earlier versions).

Download it and give it a whirl.

Visit the SalesLogix Group Explorer in the Labs

Custom Format Columns in SalesLogix Web (and Linking to External Sites in a DataGrid)

Ryan Farley — Thu, 11 Sep 2008 23:12:00 GMT

There might be times when you need to do some custom formatting in SalesLogix DataGrids that goes way beyond just simple formatting. A perfect example of this is taking a simple value, such as an indentifier from another external system where you want the value in the DataGrid to be a part of a hyperlink to this other system. In this scenario, you might have a value like "12345", which identifies a matching record in another system and you want this to become a value like the following in the grid:

<a href="http://theothersystem.com/something?id=12345">12345</a>

This is where the CustomFormatColumn column type comes in. The problem is that this column type can be a little confusing and not well documented.

In this scenario, we'll just use a sample of adding a hyperlink into the Account Contacts grid to do a Google search on the contact's full name. Not really useful, I know, but it will serve the purpose of demonstrating how to use a CustomFormatColumn.

Basically, the way that a CustomFormatColumn works is you create your own custom C# function. The value, from each row, in the grid is passed into your function. You do whatever you need to do with the value in your code and then return the result, which is what will appear in the grid.

In the DataGrid on the AccountContacts QuickForm, add a CustomFormatColumn. There are four properties we'll need to make sure we set.

ColumnHeading = The title or caption for the column.
DataField = This is field/property on the entity that you want passed into your function. For our example, we'll pass in the contact's FullName property.
FormatMethodName = This is the name that you'll be calling your function. For our example, we'll call our function "GoogleLink"
FormatCode = This is the C# code to do what is needed to the value so it displays the way you want in the grid. See the code for our example below:

protected string GoogleLink(object name)
{
    return string.Format("<a href=\"http://www.google.com/search?q={0}\" target=_blank>{0}</a>", name);
}

One thing to point out here, the parameter getting passed in will need to be an object and you'll be returning a string. Also, you must include the complete function signature with the method name matching (case-sensitive) the name you have in the FunctionMethodName property. The properties for our CustomFormatColumn will look as follows:

The thing that will look weird, is the code in the Format Code property. As I mentioned before, you must include the complete signature of the function. The code window, however, will try to tell you that the code is not valid and it will appear as if you're adding a function into a function, but you're not. The code you type into this window will get added to the SmartPart and the grid column will wrap itself in the function call. You can see the weirdness I am referring to in the screenshot:

Notice the red squigglies and the apparent method signature at the top of the window. Ignore those. You're doing just fine. After deploying, you can see the final result. A link in our grid that will launch a new window and take you to a search results page on Google.

A bit more real world, this would be another web app showing some details for that contact, like maybe products purchased or something from an accounting system. You can go far beyond simple formatting with this. If we wanted, we could pass in some identifier from the other system and then grab a value from that system's database or via a web service call to get some value to show in the grid. However, beware, that while that is possible, keep in mind that this will execute for each row in the grid, delaying the load time for the grid and SmartPart so use discretion when moving beyond simple formatting.

Public SalesLogix Web Developer Classes On The Way

Ryan Farley — Tue, 02 Sep 2008 22:08:00 GMT

Ever since the new SalesLogix 7.2 Web client and platform was released, I've had numerous requests for development training. Until now, I've done that on a very individualized basis, providing web training to single companies at a time. I've decided that it is time to make my web development training classes public, and I'd like your feedback.

The training classes will be done online, in short easy to digest chunks. The class will basically consist of 3 full days of training, spread out across three weeks. There will be approximately three sessions per week, each session lasting around 2+ hours each. To get the most out of the class, it will be expected that you spend some time working on the assigned practice examples in-between sessions.

The basic outline, for now, will consist of the following:

Beginner Track

Application Architect walk-through and terminology

QuickForms
SmartParts
Entity model and relationships
Interfaces
Portals and pages
Looking under the hood and understanding how it all comes together

Setting up new portals and development environments

IIS configuration
Deployment configuration & process

QuickForm customization
Creating new 1:1 QuickForms & entity level tabs
Creating new 1:Many QuickForms with grids and edit/detail forms
Creating and installing bundles

Intermediate Track

Creating new entities
Creating new MainView pages
Creating entity insert screens
Creating simple business rules
Creating simple entity event handlers
Troubleshooting & debugging

A look at troubleshooting both out of the box issues and your own customizations
Best practices for optimal development debugging and testing
Using tools such as Visual Studio, Reflector, Firebug, etc

Advanced Track

Creating complex business rules
Writing code for the entity model, repositories, & NHibernate queries
Creating business rules in Visual Studio
Creating custom SmartParts (visual UI elements) in Visual Studio
Creating and using mashups
Using mashups in custom SmartParts

The expert track below will likely be a completely separate class (or classes) that will not be a part of the timeline mentioned for the developer class above.

Expert Track

SData & REST

Consuming SData feeds from external applications
Creating and updating entity data via REST
Integrating SalesLogix with other systems using SData/REST

Process Orchestration (workflow)

Using process orchestration

Sequential, event driven processes
Goal driven processes

Creating new process orchestration tasks in Visual Studio
Integrating SalesLogix with other systems using process orchestration

Cost of the classes to follow at a later date. Obviously, we can't offer Sage certification, the training is meant to provide an inexpensive, easy to attend, and quick way to get developing for SalesLogix web now. The class will also focus on 7.5. Attendees will be given access to forums where discussions from class can continue, code shared, etc, to help while working through practice examples.

I'd love to hear your feedback

What topics would you like to see covered? What things have caused you frustration when working with SalesLogix Web that would be helpful in a training class? Let me know in the comments below or via the "Contact" link to the right.

Building Interfaces, Building Web Platform, and Deployment Explained

Ryan Farley — Fri, 22 Aug 2008 16:03:00 GMT

When you're developing for SalesLogix Web in the Application Architect, there are three actions that a developer must use during the process: building interfaces, building the web platform, and deployment. For someone starting out with the Application Architect, the reasons behind each of these actions can be confusing. Even more confusing can be when one is used vs another. This post will attempt to explain these three actions and when/why they are used.

Building Interfaces

If you think about how the entities are used in code, you'll know that it is always via it's interface. Basically, an interface is a sort of "contract" that another class that implements the interface must abide by. The interface has no implementation code, it only defines what the implementing class must have. The reason why the entities in SalesLogix all implement an interface, and also why these interfaces are used to reference the entities in the AA and in code, is to provide a level of abstraction from the actual implementation of the entities. This way, when "future" SalesLogix can be deployed to web, windows, or mobile, the implementation of the entities can differ if needed yet all still implement the same interface, and the code that uses them via the interfaces will still work.

So, what does that have to do with using the Application Architect? Just as your own code will use the entities via their interface, the QuickForms and other areas in the AA will use the interface as well. When you make a change to an entity, such as add a new entity, or add/change a property or relationship on and entity, the rest of the Application Architect will not know about this change until you've built the interfaces - which will cause the interface to show the change you've made. If you add a new property to an entity and then want to add it to a QuickForm, the QuickForm designer won't know about the new property unless you've rebuilt the interfaces.

As a rule of thumb, you should rebuild interfaces after doing the following:

Add a new entity
Add or change properties on an entity
Add or change relationships for entities

Now, remember this: building interfaces is only needed if you want to immediately use an entity you've added or changed in the Application Architect. The whole purpose of building interfaces is to make an entity change immediately available for use in the Application Architect. If you're not going to use that change in a QuickForm or something right away, then you don't need to build the interfaces. As you'll learn in the next section, building the web platform also builds the interfaces (so if you're going to be doing that anyway, no need to take this step).

In newer versions of SalesLogix (I think this came in 7.2.1 or 7.2.2) the Application Architect will attempt to recognize when a build is required for the interfaces and will run the build for you. I don't really like this since you'll attempt something like open up a QuickForm, it looks like the AA has locked up, but what it is really doing is running the build interfaces step in the background, when it's done it will open up the form. Instead, I like to do my own build of the interfaces when it is required.

Building Web Platform

When you build the web platform, what you're essentially doing is getting the entity model ready for a web environment. All of the business rules and event code is compiled so it is usable by the entities, the QuickForms are converted to SmartParts (ASP.NET UserControls, ascx files), and so forth. This is a required step if you've made any changes at all in the entity model, that means entities, QuickForms, relationships, business rules, etc. Remember, this step also builds interfaces, so no need to do that too. Before a deployment can happen, this must occur first to prepare the entity model by getting it into a web usable format.

As a rule, you must build the web platform after you've done the following:

Anything listed above in the building interfaces section
Created/modified a QuickForm
Created/modified a business rule, event code, or code snippet.

If you've changed anything in the entity model then you must do this step. Be clear about this, however, this is only needed with changes to the entity model only. Making changes in the portal manager, such as adding a SmartPart to a page, adding a new page, adding navigation menus, etc, are not part of the entity model, so there's no need to build the web platform, only deployment.

Deployment

The deployment is the step that pushes everything out to the website itself. The deployment process will check for the files that have changed and will push out accordingly. The deployment is needed after you do basically anything in the Application Architect to get the changes out to the website. There are some things you can do in the AA which only require a deployment with no builds or anything else. If the only changes you've are in the portal manager, such as adding a SmartPart to a page, changing where a SmartPart loads on a page or anything like that, then all you need to do is a deployment. No builds are needed. Make sense?

Yes, a lot to take in. Remember this:

Make changes to entity model and want to use the changes right away, build interfaces (unless you'll also be building web platform for other reasons)
Any change to the entity model, build the web platform
Any change mentioned in 1 or 2, deploy.
Any change to the portal manager, deploy.

Worse case, it doesn't hurt to to more than what is necessary. If a build ins't needed and you do it anyway, it won't hurt anything. However, you've realized by now that the build and deployment for SalesLogix web takes a long time. Anything to cut down on that time, and only perform exactly what is necessary is always helpful.

Error Opening InsertOpportunity.aspx in SalesLogix 7.2 Web

Ryan Farley — Mon, 28 Jul 2008 23:54:00 GMT

I posted this a while back in the SalesLogix Business Partner newsgroups, but it has recently just helped a few others who came across it there, so I thought it would be a worthwhile public post. Not everyone will get the error mentioned in this post, but if you are then this should help. This post also describes my troubleshooting process to locate this issue and determine the fix for it.

I have a customer who could not bring up the Insert New Opportunity Screen. After stepping through things with VS I determined that I was getting an error in the GetOppProductDefaults business rule on the Opportunity entity. The GetOppProductDefaults method looks like this (as seen through reflector):

public static void GetOppProductDefaults(IOpportunity opportunity)
{
    string commonOption = ApplicationContext.Current.Services.Get<IUserOptionsService>().GetCommonOption("Products", "OpportunityDefaults");
    if (commonOption != "")
    {
        commonOption = commonOption.Substring(commonOption.IndexOf("<rs:data>")).Replace("rs:data>", "rsdata>").Replace("z:row", "zrow").Replace("</xml>", "");
        XmlDocument document = new XmlDocument();
        try
        {
            document.LoadXml(commonOption);
            foreach (XmlNode node in document.SelectSingleNode("rsdata").ChildNodes)
            {
                if (node.Attributes["PRODUCTID"].Value != null)
                {
                    IOpportunityProduct item = EntityFactory.Create<IOpportunityProduct>();
                    item.Opportunity = opportunity;
                    item.Product = EntityFactory.GetById<IProduct>(node.Attributes["PRODUCTID"].Value);
                    item.Sort = new int?(Convert.ToInt32(node.Attributes["SORT"].Value));
                    item.Program = node.Attributes["PRICELEVEL"].Value;
                    item.Price = new decimal?(Convert.ToDecimal(node.Attributes["PRICE"].Value));
                    item.Discount = new double?(Convert.ToDouble(node.Attributes["DISCOUNT"].Value));
                    item.Quantity = new double?(Convert.ToDouble(node.Attributes["QUANTITY"].Value));
                    item.ExtendedPrice = new decimal?(Convert.ToDecimal(node.Attributes["EXTENDED"].Value));
                    opportunity.Products.Add(item);
                }
            }
        }
        catch (Exception)
        {
            throw new Exception("Invalid xml for default Opportunity Products");
        }
    }
}

The stack trace from the exception showed the following:

   at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
   at System.String.Substring(Int32 startIndex)
   at Sage.SalesLogix.Opportunity.Rules.GetOppProductDefaults(IOpportunity opportunity)
   at Sage.SalesLogix.Opportunity.Rules.CheckOppAccount(IOpportunity opportunity, Boolean& result)
   at (Object )
   at Sage.Platform.DynamicMethod.DynamicMethodLibrary.Execute(String methodName, Object[] args)

You'll notice that the exception was thrown from the attempt to use Substring on a string within the GetOppProductDefaults method. The Substring is used to get only the XML between the <rs:data></rs:data> tags from the serialized XML from the Recordset stored there, ignoring the schema data from the beginning section of the XML. So, I looked and this is what this customer has stored there for *all* users for the Products in the OpportunityDefaults user option:

<xml xmlns:z="#RowsetSchema" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882">
<s:Schema id="RowsetSchema">
 <s:ElementType name="row" content="eltOnly" rs:updatable="true">
  <s:AttributeType name="SORT" rs:number="1" rs:write="true">
   <s:datatype dt:type="int" dt:maxLength="4" rs:precision="0"
    rs:fixedlength="true" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="PRODUCTID" rs:number="2" rs:write="true">
   <s:datatype dt:type="string" rs:dbtype="str" dt:maxLength="12"
    rs:precision="0" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="KEYFIELDID" rs:number="3" rs:write="true">
   <s:datatype dt:type="string" rs:dbtype="str" dt:maxLength="16"
    rs:precision="0" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="PRODUCT" rs:number="4" rs:write="true">
   <s:datatype dt:type="string" rs:dbtype="str" dt:maxLength="64"
    rs:precision="0" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="FAMILY" rs:number="5" rs:write="true">
   <s:datatype dt:type="string" rs:dbtype="str" dt:maxLength="64"
    rs:precision="0" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="PRICELEVEL" rs:number="6" rs:write="true">
   <s:datatype dt:type="string" rs:dbtype="str" dt:maxLength="32"
    rs:precision="0" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="PRICE" rs:number="7" rs:write="true">
   <s:datatype dt:type="number" rs:dbtype="currency" dt:maxLength="8"
    rs:precision="0" rs:fixedlength="true" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="DISCOUNT" rs:number="8" rs:write="true">
   <s:datatype dt:type="float" dt:maxLength="8" rs:precision="0"
    rs:fixedlength="true" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="ADJPRICE" rs:number="9" rs:write="true">
   <s:datatype dt:type="number" rs:dbtype="currency" dt:maxLength="8"
    rs:precision="0" rs:fixedlength="true" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="PRICELOCAL" rs:number="10" rs:write="true">
   <s:datatype dt:type="number" rs:dbtype="currency" dt:maxLength="8"
    rs:precision="0" rs:fixedlength="true" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="QUANTITY" rs:number="11" rs:write="true">
   <s:datatype dt:type="float" dt:maxLength="8" rs:precision="0"
    rs:fixedlength="true" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="EXTENDED" rs:number="12" rs:write="true">
   <s:datatype dt:type="number" rs:dbtype="currency" dt:maxLength="8"
    rs:precision="0" rs:fixedlength="true" rs:maybenull="false"/>
  </s:AttributeType>
  <s:AttributeType name="EXTENDEDLOCAL" rs:number="13"
    rs:write="true">
   <s:datatype dt:type="number" rs:dbtype="currency" dt:maxLength="8"
    rs:precision="0" rs:fixedlength="true" rs:maybenull="false"/>
  </s:AttributeType>
  <s:extends type="rs:rowbase"/>
 </s:ElementType>
</s:Schema>
 
</xml>

There is no <rs:data> section in this XML, so obviously, that is why the use of Substring is failing, because the IndexOf is returning an invalid integer for a start position. Normally, in any other system I've checked so far, this XML is completely blank for users that have never set any defaults. For a user that goes into the dialog to set the defaults and clicks OK without selecting any default products they will have the XML, but an empty <rs:data> section. Empty is OK, because at least it exists and the code above will not fail.

So, I have no idea what caused the XML to get saved this way in the first place. I will continue to look for this in other systems, but I wanted to mention all this here in case others run into this. This is all fixed by having these users simply go into the Opportunity Defaults dialog (in the fat client) and just clicking OK. This will cause the empty <rs:data> section to be added to the XML for the serialized recordset and then all wil work fine.

I was originally going to suggest that the code for the GetOppProductDefaults be changed to check the IndexOf the "<rd:data>" section frst before proceeding to get the Substring. This certainly would have saved me some headache since the code would not have completely crapped out for this customer - but I have no idea how this got stored this way for this customer in the first place, so no telling how common this scenario would be. The weird thing is that the XML is like this for *all* users for my customer. This was an upgrade BTW, but so was my own internal database and it doesn't have this problem.

The Solution

For now, just have your users go to the Set Opportunity Defaults screen in the Windows client and just open and close (by clicking OK) the opportunity products default screen (they don't actually have to select any product defaults). This will cause the proper XML string to be saved for that user. Optionally, you could programatically store the corrected XML for them.

I've not checked yet to see if this business rule has been fixed for 7.5 or not.

SalesLogix 7.5 Beta Testing Has Begun!

Ryan Farley — Fri, 11 Jul 2008 20:55:00 GMT

The beta tesing for SalesLogix 7.5 has begun! Completely exciting. This is THE release for SalesLogix web, and one that IMO puts SalesLogix in the front of all other web-based CRM applications. If you're using SalesLogix Web and not yet planning on moving to 7.5 it's time to start planning that upgrade.

There will be plenty of things coming to show all the new features of 7.5 (like the upcoming Customer FX 7.5 Sneak Peek live workshop) , but I wanted to point out a few small and less talked about things that I've liked so far in this release.

New Look & Feel

The new "polished" look of the web client is completely impressive. I stuggled with the look of the original 7.2 client, had a hard time liking how it looked. Not the case any more. This looks awesome. Here's a few examples:

The new menus:

The new group viewer:

Collapsible navbar:

Awesome looking dialogs, especially lookups - wow those were really needed and I just can't get over how great they look!

Session Timeout Indicator

In the bottom-right corner. And you get bumped out to the login screen as soon as it expires. Small change, yes, but a nice one to have. Also, you get a count down to when you are going to get automatically logged off too - "auto logoff in 1 minute":

Performance

One completely great addition in 7.5 is that you no longer have such a long wait time when clicking between tabs. In previous versions, each time you clicked a tab you'd get the progress bar while it was retrieved and loaded. You still have the for the first time you click it, but then it stays loaded so you can go to other tabs and then back to it and it displays immediately. The result is a huge and noticeable performance increase in just moving around the client. Cool!

Deployment

I don't know if this was an intended "feature" or not, but I love it. The deployment status window is no longer modal to the Application Architect. You can deploy and then click around in the AA while the deployment is happening. No more frustrating waits just to look at some things while it is deploying.

Forms

There's a new addition of non-entity related forms! There will be plenty more to come on this one.

Anyway, off the top of my head, those are some of the smaller things that hit me as I moved around and played with the first SalesLogix 7.5 beta. Plenty more will follow.

Running SalesLogix Web on IIS7

Ryan Farley — Tue, 24 Jun 2008 21:31:00 GMT

I blogged a while back about using Vista for developing for SalesLogix 7.2 Web without using IIS but instead using the ASP.NET Dev Server. I wanted to outline some additional tweaks you can make to get the SalesLogix portals running on full-blown IIS7 on Vista as well.

While it is not officially supported to run SalesLogix 7.2 Web on IIS7, you can make some tweaks to get things running. The first thing you'll need to do is turn on (install) the IIS6 compatibility for IIS7. Don't bother looking for that in the IIS console, you add that by going to Add/Remove in Control Panel.

You need to add the IIS 6 Management Compatibility, at a minimum. To be honest, while trying to get SalesLogix working on IIS7 I tried all sorts of combinations of settings, so there may be others to add as well (leave a comment and I can check my settings to compare).

Once everything is installed, the second item has to do with the application pool for the deployed SalesLogix portal. In IIS, create an app pool for your SalesLogix Web portals. Make sure it is set to use .NET 2.0, but the important thing to set here is to use a Classic pipeline, not integrated.

Of course, also make sure your deployed SalesLogix portals are using this new app pool as well. So that is really it. You should now have it working. One more thing to note, if you're running 64-bit Vista, make sure you also read Mark Dykun's post on the additional necessary tweaks you'll have to make there as well. Good luck!

Integrating the SalesLogix Lead Capture Portal with an Existing Website

Ryan Farley — Tue, 10 Jun 2008 21:35:00 GMT

It's much easier than many might think to fully integrate the SalesLogix 7.2 Lead Capture portal into an existing website. For a sample of this, I grabbed a free online website template and put it up as a website and within 5 minutes (seriously, 5 minutes) I had the Lead Capture portal fully integrated into the site. Brain-dead easy. Best of all, no frames.

So, I've created a free workshop on June 24th (Tuesday) at 2:00PM Central to cover this topic and demonstrate how to integrate the lead capture portal with an existing website. If you'd like to attend you can register here: Click to Register

Join me on the workshop (it's free) and we can take a look at this together and discuss different scenarios for websites built on different technologies (doesn't need to be an ASP.NET site).

See you there.

Using the EntityHistoryService to Retrieve Previously Accessed Entities

Ryan Farley — Fri, 30 May 2008 23:16:00 GMT

There are many ways to get the "current" account in SalesLogix Web. For those coming from developing for the SalesLogix Windows client, you'll likely want the same capabilities that the BasicFunctions CurrentAccountID provides. In the web platform, however, there is all of that, plus more.

If your QuickForm or SmartPart is a child of the Account entity, you can reference the parent account instance using GetParentEntity:

Sage.Entity.Interfaces.IAccount account = 
    (Sage.Entity.Interfaces.IAccount)this.GetParentEntity();

If the parent of your SmartPart is an account (meaning your SmartPart is on an entity page for type IAccount), then that will get it for you just fine.

Another option, which is a bit more limited, is to get the parent account for the current entity instance. This will, of course, only work if your current entity instance has a parent account. For example, let's say your on a Contact-level SmartPart and you want to get the parent account:

Sage.Entity.Interfaces.IContact contact = 
    this.BindingSource.Current as Sage.Entity.Interfaces.IContact;

if (contact != null)
{
    Sage.Entity.Interfaces.IAccount account = contact.Account;
    //...
}

This works great if you have a parent account for the current entity instance. Let's say that you create an entirely new area for the client and you'd like to default the account to the current account (or really the last account the user visited) when creating new instances of your entity. The Sage Platform provides an Entity History Service for just this purpose. In the sample code below let's grab a reference to the last account visited:

// First access the EntityHistory service 
Sage.Platform.Application.IEntityHistoryService entityHistoryService = 
    Sage.Platform.Application.ApplicationContext.Current.Services.Get<IEntityHistoryService>();

// Now let's use it to get the ID of the last Account accessed 
string accountId = entityHistoryService.GetLastIdForType<IAccount>().ToString();

// And get a reference to the entity 
IAccount account = Sage.Platform.EntityFactory.GetById<IAccount>(accountId);

You can also use that service to to back much further, beyond just the last entity accessed, but all the past ones accessed. Let's say you want to get a list of all previously accessed accounts:

List<string> accountlist = new List<string>();
foreach (EntityHistory entity in entityHistoryService)
{
    if (entity.EntityType == typeof(IAccount))
    {
        accountlist.Add(string.Format("Accessed {0} ({1})", entity.Description, entity.EntityId));
    }
}

Let's see you do that in the Windows client. Do I have to keep saying that I love this new platform, or can we all just agree that it rocks? Hehe.

Binding a Grid to a List Returning Business Rule using GetByMethod

Ryan Farley — Tue, 27 May 2008 22:15:00 GMT

I last posted about creating a business rule to return a list of objects. Today, I will take that a step further and bind the List<IAccount> to a DataGrid using the built-in GetByMethod for binding the list.

In my last post I created a business rule that returned a list of child accounts for the current account named GetChildAccounts. Now, we will create a new account level tab to display this data. Let's start with the following:

Create a new form under the account entity (I don't typically use the wizards)
Add a DataSource to the form and set the following properties on it:

Entity Type = Account
Get By Method = GetChildAccounts
Is Collection = True
Source = Account

Now add a DataGrid and select the DataSource and add your columns as usual.

You'll end up with the following:

Quite nice and an easy peice of work. I just love the new platform.

Creating a Business Rule to Return a List of Objects

Ryan Farley — Thu, 22 May 2008 18:05:00 GMT

One of the best things about working with the SalesLogix 7.2 Web application is how great the entity model is. You have this single place to put all your rules and logic, the UI is really just an afterthought. Something that I do quite often is create business rules to return data specific to an entity instance. For example, a rule to return the primary contact for an account. Let's take that a step further and return a list of objects from an business rule. For this scenario, we'll create a business rule that will return a list of child accounts for the current account instance.

To do this, go to the Account entity in the Application Architect and create a new business rule. Give the rule a name of GetChildAccounts. What we will be returning from this rule is a List<IAccount>. However, you'll get problems if you try to add that as the return type for the rule in some versions. That's fine, we can specify that we'll be returning an object and all will be OK (otherwise, add System.Collections.Generic.IList<Sage.Entity.Interfaces.IAccount> as the return type). Add a step for the rule and it will end up looking like the following:

Click the Edit Code Snippet and we'll enter the following code:

#region Usings
using System;
using Sage.Entity.Interfaces;
using Sage.Platform;
using Sage.Platform.Repository;
#endregion Usings

namespace Sage.BusinessRules.CodeSnippets
{
    public static partial class AccountBusinessRules
    {
        public static void GetChildAccountsStep1( IAccount account, out object result)
        {
            IRepository<IAccount> repository = EntityFactory.GetRepository<IAccount>();
            IQueryable qry = (IQueryable)repository;
            IExpressionFactory ef = qry.GetExpressionFactory();
            
            ICriteria criteria = qry.CreateCriteria();
            criteria.Add(ef.Eq("ParentId", account.Id.ToString()));
            
            result = criteria.List<IAccount>();
        }
    }
}

Let's talk about what that code is alll about for a sec. We first create a repository for IAccount. This is basically the "place" and "type" where we will be getting our data. We next create an IQueryable object which represents our query. We add an ICriteria, via the ExpressionFactory of our IQueryable object, which specifies that we want anything from our repository that meets the criteria that the entity's "ParentId" property equals the current account instance's Id value. From there we simply get a List of the results. I'll be posting a lot more about how to use and understand this syntax in the future, but I wanted to point out that it is all NHibernate under the covers. This means you can use HQL queries as well, which might make for more readable syntax for some. Either way, there is plenty of good info online already. See http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html_single/#querycriteria for starters.

Tomorrow we'll look at binding those results to a grid using the GetByMethod option for the datasoruce.

Ping a Remote Server Using C#

Ryan Farley — Thu, 22 May 2008 04:30:00 GMT

In my last post, I shared some code in VBScript to PING a remote server to check for availability before attempting to use a resource on that remote server. This wouldn't be my blog if I didn't also share this code in C# as well. IMO, this sort of thing is a far better suited for a .NET Extension if for the SalesLogix Windows client.

To perform a PING using C#, the code is far more straight forward than the VBScript version. No need for shelling the command out and reading back the StdOut. This version reads much nicer:

using System;
using System.Management;

namespace FX.Network.Utility
{
    public class NetworkDiscovery
    {
        public NetworkDiscovery() { }

        public static bool Ping(string Target)
        {
            SelectQuery query = new SelectQuery("Win32_PingStatus", string.Format("Address='{0}'", Target));
            ManagementObjectSearcher searcher = new ManagementObjectSearcher(query);

            foreach (ManagementObject result in searcher.Get())
            {
                return (result["StatusCode"] != null && (0 == (UInt32)result["StatusCode"]));
            }
            return false;
        }
    }
}

Enjoy!

Ping a Remote Server Using VBScript

Ryan Farley — Mon, 19 May 2008 15:55:00 GMT

At times you might build a customization in the SalesLogix LAN client that relies on networked resources. For example, you might consume a web service or other resource that is available to LAN users and remote users via VPN. In this scenario, and many others like it, you have the potential to have remote users that do not currently have access to this networked resource. Even worse, you might have remote users that may not even be online at the time. A quick PING can check for availability.

You can perform a PING by executing the PING command-line via the Shell. Here is a reusable function to do just this:

Function Ping(Target)
Dim results

    On Error Resume Next

    Set shell = CreateObject("WScript.Shell")
    
    ' Send 1 echo request, waiting 2 seconds for result 
    Set exec = shell.Exec("ping -n 1 -w 2000 " & Target)
    results = LCase(exec.StdOut.ReadAll)
    
    Ping = (InStr(results, "reply from") > 0)
End Function

Now to use that code you simply pass the IP address or hostname to the Ping function and check the boolean result

If Ping("192.168.1.100") Then
    ' Do something to access the resource
End If

You can optionally adjust the number of times the ping request is sent and the timeout interval to wait for the result.

RESTful Web Services Coming in SalesLogix 7.5

Ryan Farley — Wed, 14 May 2008 15:38:00 GMT

This week I've been in Washington DC attending the Sage Insights Business Partner conference. It's been great meeting up with friends in the business partner community and the guys from Sage. There's been a lot of discussion about things coming in the next release, version 7.5 (codenamed "Sahara") and in the release beyond that (codenamed "Tanami"). The focus for SalesLogix is definitely shifting to web, not that the windows side is being neglected, but it reflects the shift in the industry to web-based applications, which I think is awesome. Of all the new details that have been shared about the Sahara release (See my previous post on new features coming in 7.5), by far, one of the more exciting is the introduction of the RESTful web services layer.

This is just huge and introduces a whole new level of capabilities for SalesLogix. For those who might not be familiar with REST (See Wikipedia), it basically comes down to URL addressable resources and simplifies the use of these resources while taking the programmable web to the level of functionality contained within the browsable web - in a way that is far superior (IMO) to SOAP.

OK. For SalesLogix, the REST services all use an SData protocol to define the structure of the URL for accessing resources. As an aside, the great thing is that this SData protocol is meant to eventually be common accross all Sage products, providing a unified way to integrate Sage applications. Maybe that's a pipe dream, time will tell. I'm just thrilled to have it coming in SalesLogix. These services will be able to read data, such as groups, named NHibernate HQL queries, and even perform CRUD functions (CReate, Update, Delete)! Business rules won't be accessible via the REST layer for the initial version, but the entity level eventing will. This is where the real power comes from. You'll have a common place to implement business rules for entity events that is made available to any/all SalesLogix applications, addons, external applications, etc. BTW, these entity level events are available in this way due to a move to the provider level. The SalesLogix OLEDB Provider will raise entity level events, executing the code you've defined there - so these events will basically apply throughout SalesLogix. Woot!

For data returning RESTful GET calls, the data can be returned in one of three formats:

XML
JSON
ATOM (current default)

So what do these URL addressable resources look like? Well, for example, let's say you want to return all accounts, your URL would look like the following:

http://<server:port>/sdata/slx/accounts

How about a specific account:

http://<server:port>/sdata/slx/accounts(AXXXX0000001)

List all contacts for a specific account:

http://<server:port>/sdata/slx/accounts(AXXXX0000001)/Contacts

You get the idea. The SData protocol/scheme is very well thought out and I could not be more pleased with how this has been implemented. It goes much deeper than what I've covered here, the ability to perform HQL queries via REST is so completely powerful. The fact that we'll be able to perform basic CRUD operations as well was a VERY welcome surprise. For sure, there will be much more to come from me on this subject in the future.

Account Hierarchy for SalesLogix 7.2 Web Released

Ryan Farley — Fri, 09 May 2008 23:15:00 GMT

I've released a free addon for SalesLogix 7.2 Web for account relationships in the Customer FX Labs. The account hierarchy screens that exist in the SalesLogix Windows client is missing for the SalesLogix 7.2 Web Client. This bundle will bring this functionality into the web client. The addon works exactly the same as this functionality in the windows client. Full source included.

Click for larger view

Download the Account Hierarchy bundle for SalesLogix Web

Download and enjoy!

Elegant SalesLogix Table ID Class in C#

Ryan Farley — Wed, 07 May 2008 18:21:00 GMT

I've been using the following C# class for creating SalesLogix table ID values lately and I just love the elegant syntax it provides. It's really been growing on me.

Here is the class:

using System;
using System.Data.OleDb;

namespace SalesLogix.Utility
{
    public class TableID
    {
        private string _table = string.Empty;

        public TableID(string TableName)
        {
            switch (TableName.ToUpper())
            {
                case "ATTACHMENT": _table = "FILEATTACH"; break;
                case "USERNOTIFICATION": _table = "USERNOTIFY"; break;
                case "AGENTS": _table = "HOSTTASK"; break;
                case "RESOURCELIST": _table = "RESOURCE"; break;
                case "USEROPTION": _table = "USERVIEW"; break;
                case "JOINDATA": _table = "JOIN"; break;
                case "PROCEDURES": _table = "PROCEDURE"; break;
                case "SEC_FUNCTIONOWNER": _table = "FUNCTIONHANDLER"; break;
                default: _table = TableName; break;
            }
        }

        public override string ToString()
        {
            return this.Value;
        }

        public string Value
        {
            get
            {
                using (OleDbConnection conn = new OleDbConnection(Globals.ConnectionString))
                {
                    conn.Open();
                    using (OleDbCommand cmd = new OleDbCommand(string.Format("slx_dbids('{0}', 1)", _table), conn))
                    {
                        return cmd.ExecuteScalar().ToString();
                    }
                }
            }
        }
    }
}

Nothing out of the ordinary there, but the really nice part comes from it's usage:

string ticketid = new TableID("ticket").Value;

I like it :-)

SalesLogix 7.2 Web on Vista

Ryan Farley — Fri, 02 May 2008 19:59:00 GMT

In a recent conversation in the business partner newsgroups, it was brought to my attention by Mark Dykun that either due to changes from SalesLogix v7.2 SP2 or from Vista SP1 that the SalesLogix Web client will work on Vista (in a limited capacity). It still won't work on IIS7, but it will work when running through the ASP.NET Web Development Server. The Development Server is included with the .NET Framework 2.0 and works by running a small web server to host a local ASP.NET site for development or testing purposes, similar to Cassini. The last I tried this was with SalesLogix v 7.2.0 and it definitely didn't work then. But it does now (huge hooray!).

Mark followed this conversation up with a post on his blog where he outlines how to create a batch file to launch the Development Web Server on the command-line and point to the deployed SalesLogix Web site. This is a great approach, however, I wanted to point out an alernative as well that is built right into the Application Architect. When you right click on a Portal in the Application Architect, you have a menu option available called "Test Portal".

That this option does is deploy the portal to a temporary location and then launches the site in the ASP.NET Development Web Server automatically. Both steps in one action. The complete steps that this Test Portal option does are as follows:

Deploys the site to the following location:
```
C:\ProgramData\Sage\Platform\WebPortal\Design\SlxClient_TEST
```
where "SlxClient" is the name of the Portal. BTW, this is the same location that the site will get copied to when you use the "Pre-Compile" option in the deployment. The AA will copy the site here, precompile it using the aspnet_compiler.exe in the .NET Framework and then deploy the compiled result to the actual deployment location (unless you have the "In-Place Compile" option checked)
The AA will then launch the .NET Development Web Server pointed to that location on port 8080.
A browser window will then automatically open pointing to the server running on port 8080.

So, you save the step of deploying, running your batch file, then launching the browser to that location. It does it all in one step, and best of all, right from within the Application Architect. You can also still open Visual Studio and point to the deployment directory (the "actual" deployment directory or to the "TEST" location where the files were copied to from the "Test Portal" option) and run the site from VS as well.

Anyway, I was completely excited to find that this works now. I don't know if it was a change in SP or Vista, but I don't really care. I'm just excited to be able to test/develop a local site on Vista, even if it is in a limited capacity. It would be nice to be able to run the site right on IIS7, and that support will eventually come, but for now, this new find was much needed! Goes to show you have to keep trying the stuff that didn't work before with each new version, because you'll never know what sneaks it way in! A HUGE thanks for Mark for getting me to try it again.

GetField Equaivalent for C# using Generics

Ryan Farley — Mon, 28 Apr 2008 22:08:00 GMT

Many people who customize SalesLogix have become accustomed to using the built in "SLX Database Support" script to provide things like the quick and easy GetField function to return a single database value. If you've ventured into the .NET Extensions realm, you might want an easy equivalent. The following is a repost of something I posted around a year ago in the Sage Business Partner newsgroups:

QUESTION:
Does anyone have a generic GetField function for C# .Net? One that can handle N DataTypes, Nulls, DbNull, etc.? I am playing with the SLX VB script function, and it doesn't adapt well to the strongly typed fields of C# .NET. Specifically the ExecuteScalar() blows up on 1) TheValue has no type 2) can't handle nulls 3) can't handle int....Any ideas or do I need specific GetFieldInt, GetFieldDateTime, GetFieldString stuff?

This is why we have generics! You could implement the GetField method as method that returns a generic type. That would be the best way to do it! Here's a quick sample:

public T GetField<T>(string Field, string Table, string Where)
{
    string sql = string.Format("select {0} from {1} where {2}", Field, Table, (Where.Equals(string.Empty) ? "1=1" : Where));
 
    using (OleDbConnection conn = new OleDbConnection(SlxConnectionString))
    {
        conn.Open();
        using (OleDbCommand cmd = new OleDbCommand(sql, conn))
        {
            object fieldval = cmd.ExecuteScalar();
            return fieldval == DBNull.Value ? default(T) : (T)fieldval;
        }
    }
}

Now to use it, you'll specify the type like this:

// for a string field
string accname = GetField<string>("account", "account", "accountid = '" + accid + "'");
 
// or for an int field
int numemp = GetField<int>("employees", "account", "accountid = '" + accid + "'");
 
//or for a datetime field
DateTime createdon = GetField<DateTime>("createdate", "account", "accountid = '" + accid + "'");

Get the idea? How's that for cool?!

Creating Sections for Controls on SalesLogix Web QuickForms

Ryan Farley — Wed, 23 Apr 2008 17:50:00 GMT

A common thing that any developer will do when creating a form for an application is to create sections for controls to group similar controls in a panel or other container, making it easy for the user to see that the values are related. There isn't exactly support for creating these "sections" in the SalesLogix Web QuickForms. With a quick bit of tweaks we can easily accomplish this result.

A new control was introduced in 7.2.2 in the Application Architect. This new control is called a "Control Container". This control is a non-visible container that is most commonly used to show or hide a group of controls at runtime on a QuickForm. If we look at what happens with this control when we build the web platform and deploy, we'll see that it ends up as an <asp:Panel>. Not only that, it actually has a CssClass attribute set. Cool. What this means is that we can create a style for this panel to give it a visual border by just adding the style to one of the SalesLogix style sheets. The style class used is "controlslist". This class is not currently defined in the 7.2.2 style sheets so we will add it ourselves in a bit.

To start, open your QuickForm in the Application Architect and add a Control Container to it. Add your controls to the container. What I like to do is also add a Horizontal Separator above the Control Container and set a Caption for the Horizontal Separator as well so it looks like a header for my section. My form in AA will look like the following:

I have my Horizontal Separator with a Caption of "Test Section" and a Control Container with 2 controls in it, a TextBox and a Button. Now, when I build and deploy the form, the Control Container will get created on the SmartPart as an <asp:Pane>, which at runtime will render as a <div>. Before deploying, we'll still need to add our style attributes to give this a visual look. In the Portal, go to the Support Files\CSS and open "SlxBase.css". Add to it the following:

.controlslist
{
    border: solid 1px #B5CBE0;
    padding: 5px; 
    margin: 7px;
}

Now we can deploy the site and the end result will look like this:

(With Horizontal Separator above the Control Container)

(Without the Horizontal Separator)

That is it. While that isn't quite as nice as using a FIELDSET or other section with a heading, I think that turned out plenty nice. If you need more flexibility than that for creating visible sections, you'd have to resort to building it as a custom SmartPart, instead of as a QuickForm. Another downside to this approach is that you've defined the border for all Control Containers. So, other Control Containers in the system will get this same look, whether you want it to have it or not.

Edit

I was thinking that it would be pretty easy to have this style and not have it apply to all Control Containers. A new property in 7.2.2 for most controls is one called StyleScheme. This property has been confusing for most since it has a drop-down and the only thing that appears in it is "NegativeNumber". However, you *can* just type in a value there and the value will get rendered out as the CssClass. If the selected control already renders a CssClass value then yours will get add to it (like this CssClass="controlslist MyCustomStyleClass", so both will still apply. For our solution, we could add the style class to SlxBase.css for "ControlSection" instead of "controlslist". Then, for any Control Containers we want to have this look we could just enter "ControlSection" in the Control Container's StyleScheme property. Then only those with this StyleScheme will have the "bordered" look to it instead of all Control Containers.

Adding a Parent Lookup to the AccountDetails Form in SalesLogix Web

Ryan Farley — Mon, 21 Apr 2008 17:25:00 GMT

I posted a while back about creating missing client functionality in the SalesLogix Web Client. In that post, I shared a screenshot of a custom "Account Hierarchy" screen I built for the SalesLogix Web Client. I'll be sharing that screen in the Customer FX Labs in the future. For now, I'll cover how to add the lookup for "Parent Account" on the Account Details form.

To add the Account Parent Lookup to the AccountDetails form, add the Lookup and then set the following properties:

Caption = "Parent:"
Allow Clearing Result = True
DataBindings = Map ParentId to LookupResultValue
Lookup Entity Name = Account
Lookup Binding Mode = String
Return Primary Key = True
Enable Hyperlinking = True
LookupProperties = Select the columns you want available in the Lookup

The result will look like this (after building the web platform and redeploying):

For these steps I am linking it as a string instead of using a relationship for an object property. I wanted to avoid the circular relationship from account back to account. Stay tuned for my Account Hierarchy Form to be available soon in the Customer FX Labs.

Displaying the Primary Contact on the Account Detail Form Revisited and Custom Properties in 7.2.2

Ryan Farley — Fri, 18 Apr 2008 20:29:00 GMT

I posted before about adding the primary contact to the Account Details form in the SalesLogix 7.2 Web Client. This solution made use of "Custom Properties" which was a feature available in 7.2.1. However, since that time, a change was introduced to how custom properties are built in 7.2.2 and later. Custom Properties are no longer available (although custom properties built prior to 7.2.2 will still work when you upgrade without change).

Let's take a look at how this changes things using the same example as before (placing the account's primary contact on the account details form). As I mentioned, Custom Properties are gone. We now have "Code Snippet Properties". The major difference between a 7.2.1 Custom Property and a 7.2.2 Code Snippet Property is that a Code Snippet Property is the following:

Code Snippet Properties are read-only. That is, they have a getter only, no setter.
The code in a Code Snippet property is no longer exactly a part of the entity. This measn that before, you could reference properties/methods of the entity using "this", while now, you are passed in a reference of the entity as a parameter.
The implementation of the actual code for the Code Snippet Property is a void method. That's right. It doesn't actually "return" anything. Instead, there is an out parameter (of type "object") that you set as the return value.
While the implementation code is a void method with an out param for the result, you still use it as a property. There is a property that will wrap the method and allow you to use it like a property. This allows you to still easily bind it.

All of this change was mainly to separate the code for the property from the entity itself, allowing the implementation code to be in C# or VB.NET, whereas before you could only use C# (which was fine with me, hehe).

Anyway, to create the "PrimaryContact" property, there are only small changes we'll need to make. First of all, right-click on the Account entity Properties folder and select "New Code Snippet Property". You'll get the following:

You'll want to set the following:

Property Name: PrimaryContact
Return Type: Sage.Entity.Interfaces.IContact (just like before, you'll have to just type this in. It won't appear in the drop-down list)
Click Add. This will create the step's snippet stub
Click Edit Code Snippet. This will bring up the code window

Now enter in the following code:

namespace Sage.BusinessRules.CodeSnippets
{
    public static partial class AccountBusinessRules
    {
        public static void GetPrimaryContactStep1(IAccount account, out Sage.Entity.Interfaces.IContact result)
        {
            Sage.Entity.Interfaces.IContact primarycontact = null;
            foreach (IContact contact in account.Contacts)
            {
                if (contact.IsPrimary.HasValue && contact.IsPrimary.Value)
                {
                    primarycontact = contact;
                    break;
                }
            }
            result = primarycontact;
        }
    }
}

You'll notice that the current account reference is passed in as a parameter to the method and that you'll set the out param as the return value. That is it. Build the interfaces and then you can add it to the Account Details form just like I had posted earlier (see previous post).