CRM Developer

Extracting Reports from the SalesLogix Plugin Table from External Applications

2009-05-29T20:09:00Z

There are many reasons why extracting a SalesLogix Report from the SalesLogix database might be useful. There are possibilities of integration, automated running of reports, as well as the need to generate a PDF from some code on a server using a SalesLogix Crystal report.

SalesLogix stores reports in the DATA field, which is a binary (BLOB) field in the PLUGIN table. Not just the report, but the SalesLogix report plugin, which contains not only the report itself but also the plugin info for the report. All together in a single BLOB field. This BLOB field is the serialized Delphi class named TCRWReportWrapper with the report file bytes appended to the end of the serialized class bytes.

Luckily, a serialized Delphi class will always end in two consecutive NULL bytes (0x00, 0x00) and will never contain two consecutive NULL bytes internally. This makes out job a bit easier in knowing where the serialized Delphi class ends and the bytes making up the report file begin. We can read out the bytes from PLUGIN.DATA for the report record and then read through them until we find the two consecutive NULL bytes, when write out everything following to a file and we'll have the report itself.

Here is some C# code to do just that:

using System;
using System.Data;
using System.Data.OleDb;
using System.IO;
 
namespace FX.SalesLogix.Utility
{
    public class ReportExtractor
    {
        public ReportExtractor(string ConnectionString)
        {
            this.ConnectionString = ConnectionString;
        }
 
        public string ConnectionString { get; set; }
 
        public void GetReport(string PluginID, string DestinationFile)
        {
            using (OleDbConnection conn = new OleDbConnection(this.ConnectionString))
            {
                conn.Open();
                using (OleDbCommand cmd = new OleDbCommand("SELECT DATA FROM PLUGIN WHERE PLUGINID = ?", conn))
                {
                    cmd.Parameters.Add(new OleDbParameter("PLUGINID", PluginID));
 
                    // Get the plugin byte array
                    byte[] data = (byte[])cmd.ExecuteScalar();

                    // Look for the two consecutive null bytes
                    int idx = 0;
                    for (int i = 0; i < data.Length; i++)
                    {
                        if ((int)data[ i ] == 0 && (int)data[i + 1] == 0)
                        {
                            idx = i + 2;
                            break;
                        }
                    }
 
                    // Get everything after the two consecutive bytes
                    byte[] rpt = new byte[data.Length];
                    Array.Copy(data, idx, rpt, 0, data.Length - idx);
 
                    // Write out to an RPT file 
                    using (FileStream f = new FileStream(DestinationFile, FileMode.CreateNew))
                    {
                        f.Write(rpt, 0, rpt.Length);
                        f.Close();
                    }
                }
            }
        }
    }
}

To use the code you'd do something like the following:

// Extract report to C:\MyReportFile.rpt
ReportExtractor rptextractor = new ReportExtractor(MyConnectionString);
rptextractor.GetReport("pDEMOA0000HQ", @"C:\MyReportFile.rpt");

Now you can do whatever you'd like with the report such as open it in an RDC object and generate a PDF from it.

Determining the Page Mode at Runtime in SalesLogix Web

2009-04-20T18:42:00Z

One of the keys to reusing a form for both inserting new records and displaying existing record detail is the ability to determine if the form is currently in insert mode or detail mode. There are several ways to determine this at runtime so you can take the necessary steps depeding on the current form mode.

Out of the box, there are three defined form types: Detail, Insert, & List

Some of the code we'll use will differ whether you're using a C# Snippet Action (where the code is added to the form itself) or a Code Snippet Action (where the code is added to a separate assembly and you're passed an adapter object to access limited form properties).

From a C# Snippet Action

Use the following code to access the exposed EntityForm property of the form and determine the form mode.

if (EntityPage.IsInsertMode)
    labelMode.Text = "Insert Mode";
else
    labelMode.Text = "Not insert mode";
 
 
// or
 
 
if (EntityPage.ViewMode == Sage.Platform.Orm.Entities.EntityViewMode.Insert)
    labelMode.Text = "Insert Mode";
else
    labelMode.Text = "Not insert mode";

From a Code Snippet Action

For a Code Snippet Action, you'll need to do things a little differently. In a Code Snippet Action you're only passed an adapter, or a wrapper, for the form, not the form itself. So, the problem is that you cannot access the page's EntityPage reference. You can still get to it however, you'll just have a few extra steps to dig through. Luckily, the form adapter exposes the SmartPart via the NativeForm property.

// First get a reference to the underlying SmartPart itself
Sage.Platform.WebPortal.SmartParts.SmartPart smartpart = form.NativeForm as Sage.Platform.WebPortal.SmartParts.SmartPart;
// Now get the SmartPart's parent page and use it as an EntityPage
Sage.Platform.WebPortal.EntityPage page = smartpart.Page as Sage.Platform.WebPortal.EntityPage;
// Now you can proceed as normal...

if (page.IsInsertMode)
    form.labelMode.Text = "Insert Mode";
else
    form.labelMode.Text = "Not insert mode";
 
 
// or
 
 
if (page.ViewMode == Sage.Platform.Orm.Entities.EntityViewMode.Insert)
    form.labelMode.Text = "Insert Mode";
else
    form.labelMode.Text = "Not insert mode";

Checking the Entity's ID Property

One last way you can use to check to see if the page is in Insert mode is to check the entity's Id property. If it is null then you have a new entity, not yet persisted to the database.

if (myentity.Id == null)
    // this is a new entity

The problem is that it is possible that this won't infer the correct mode. That is telling you that the object hasn't yet been persisted to the database, which might be enough, but you might want different behavior for new objects on the form vs the form being in insert mode itself. Just make sure that if you use this method to determine the page mode that you understand the differences so you know what you're really checking.

Accessing the Current Parent Entity from a Code Snippet Action

2009-04-08T15:00:00Z

The transition from using pre-version 7.5.1 "C# Snippet Actions", where the code is placed inline in the form, and the new "Code Snippet Actions", where the code is compiled into a separate DLL and a psudo-form reference is passed in, can be frustrating at times. I ran into yet another instance of that today. Before, we were spoiled using the C# Snippet Actions. We had access to everything on the form. Everything. That's no longer the case with Code Snippet Actions. While in a Code Snippet Action, I needed a reference to the current parent entity (not the current entity that is exposed via form.CurrentEntity, but it's parent). This Code Snippet Action was on a LoadAction of an Insert screen so the parent had not yet been set. Let's take a look at how to solve that.

Before you go on, read a previous post of mine where I discuss the differences between C# Snippet Actions and Code Snippet Actions if you've not done so already: Setting the Default Sort for a DataGrid in SalesLogix Web REVISITED

The Problem

The problem I needed to solve was get the current entity's parent from a LoadAction on an insert screen. At that time the parent had not yet been set so we couldn't just use myentity.ParentEntity to get it. If this were an older C# Snippet Action then I could have simply used the following:

IMyParentEntity myparent = this.GetParentEntity() as IMyParentEntity;

That would have been great. But this wasn't in a C# Snippet Action and "this" in a Code Snippet Action is an entirely different thing where GetParentEntity did not exist. My first thought was to use the form.NativeForm and cast it as an EntityBoundSmartPart. That seemed logical. The cast worked, however when I attempted to call GetParentEntity it failed due to it's protection level. Doh! It is protected so I can't call it from another assembly.

The Solution

Thankfully, one of the most useful things the form referenced that is passed in has is the page's WorkItem. Through the WorkItem you can get a reference to one of the many useful services in the portal. In this case, the EntityContextService. The EntityContextService has a method named GetEntity that will give you the currently accessed entity. Not the child entity that my dialog was for, but the entity the page itself is for, my parent entity. I wired up the following code:

// Get a reference to the EntityContextServce
// and call GetEntity() 
IMyParentEntity myparent = form.WorkItem.Services.Get<Sage.Platform.Application.IEntityContextService>().GetEntity() as IMyParentEntity;

That is it. It works and it isn't so bad. However, I do miss the C# Snippet Actions as well. I realize I can still use them even though they are marked as obsolete, however, I think there is also value in learning the new way to do things and living with the changes.

Adding a Default Sort to the Add Opportunity Products List in SalesLogix Web

2009-04-07T14:27:00Z

Usually by the third time I see a question asked, I realize it needs to be a blog post. I've been asked by a couple of customers how to add a default sort to the products list on the Add Opportunity Products form in the SalesLogix Web client. The question of how to add a default sort to the list of products in the Add Opportunity Products form in the web client surfaced again today so I am posting the answer here.

The approach to sorting the products list on the Add Opportunity products form is different than what I have outlined before for simply sorting a grid. The opportunity products list is not a DataGrid, but a Tree control.

To sort the products list, instead of telling the control to sort, we will just sort the list of objects that it is bound to.

First, locate the AddOpportunityProduct SmartMart. This is a custom SmartPart, not a QuickForm, so you won't find this under the Opportunity entity itself, but instead in the Sage SalesLogix Portal in following location (we'll just need the code-behind, or "cs" file for this, not the "ascx" file):

Support Files\SmartParts\Opportunity\AddOpportunityProduct.ascx.cs

Double-click that file to open it in the Application Architect. In the code, look for the method named GetProductList. You'll see the following two lines at the very end of that method:

List<Product> ProductList = criteriaProduct.List<Product>() as List<Product>;
return ProductList;

Right before those two lines, add the following line (in this case, we'll sort the list by family):

criteriaProduct.AddOrder(expProduct.Asc("Family"));

Obviously, you can replace "Family" with any other valid property name on the Opportunity entity to sort the results by.

Filtering a DataGrid in SalesLogix Web at Runtime

2009-04-02T17:22:00Z

Binding a DataGrid at runtime is something that many SalesLogix developers are used to doing while working in the LAN client. This task is every bit as easy in the web platform as well. Let's take a look at how to put this together.

Scenario

For this example, we will put together a tab on the account page. We'll call this tab "Related Accounts". It will have a Picklist, showing the Account Types picklist, and a DataGrid. As the user selects an account type value in the picklist we will display all accounts with that account type. Not a really useful customization, but one that will allow us to see how to bind the grid up at runtime using a user selected value.

Building the Solution

To put this together, let's start with building a busioness rule that we'll use to return the data for the grid. You can read more about using GetByMethod to bind a grid to a rule in my previous articles: Creating a Business Rule to Return a List of Objects and Binding a Grid to a List Returning Rule using GetByMethod.

Our business rule will return a list of accounts and will take in one parameter, which will be the user selected account type value. The rule will look like this:

Name: GetRelatedAccounts
Return Type: System.Collections.Generic.IList<Sage.Entity.Interfaces.IAccount>

Add a parameter as follows (click on the Add link in the Parameters section):

Parameter Name: TypeValue
Type: String

Now for the code:

public static void GetRelatedAccountsStep(IAccount account, string TypeValue, out System.Collections.Generic.IList<Sage.Entity.Interfaces.IAccount> result)  
{
    IRepository<IAccount> repository = EntityFactory.GetRepository<IAccount>();
    IQueryable qry = (IQueryable)repository;
    IExpressionFactory ef = qry.GetExpressionFactory();

    ICriteria criteria = qry.CreateCriteria();
    criteria.Add(ef.Eq("Type", TypeValue));

    result = criteria.List<IAccount>();
}

Now, we'll need one more business rule. The SalesLogix DataGrid control itself will throw an error if it does not have a DataSource set at build time. We're not going to really use the SalesLogix DataSource component at all since we'll be binding up the grid at runtime. However, it still requires this or it won't build. To get around this we will have to add a DataSource component to the form as well. Now, we'll also get errors if we have a DataSource component that is not set to return some data. We can't use GetByMethod with our new rule we created since our rule takes a param and there is no way to set that for the DataSource. What we will do is create another business rule that returns a blank, empty list of accounts and we'll use that for the DataSource, just so things compile.

This is what our empty rule will look like:

Name: GetEmptyAccountList
Return Type: System.Collections.Generic.IList<Sage.Entity.Interfaces.IAccount>

The code will be as follows:

public static void GetEmptyAccountListStep( IAccount account, out System.Collections.Generic.IList<Sage.Entity.Interfaces.IAccount> result)  
{
    result = new System.Collections.Generic.List<IAccount>();
}

Now you can use that rule that returns an empty list to set up as the GetByMethod for the DataSource component and then wire the DataSource to the grid. Also throw a Picklist onto the form using the Account Type picklist.

The picklist will have some code in the OnChange action. Add a "Code Snippet Action" to the OnChange of the Picklist control. The code for that will look as follows:

public static void picklistType_OnChangeStep(IRelatedAccounts form, EventArgs args)
{
    // Get a reference to the underlying ASP.NET GridView control
    System.Web.UI.WebControls.GridView grid = (System.Web.UI.WebControls.GridView)form.gridAccounts.NativeControl;  

    // Make sure a value was selected in the Picklist
    if (form.picklistType.PickListValue != null && form.picklistType.PickListValue != string.Empty)
    {
        // Get a reference to the account and call the rule, passing the picklist value
        IAccount account = form.CurrentEntity as IAccount;                
        grid.DataSource = account.GetRelatedAccounts(form.picklistType.PickListValue);
    }
    else
        grid.DataSource = null;

    // Call the DataBind method of the GridView to set the binding 
    grid.DataBind();
}

That is it. The key is to get a reference to the native underlying ASP.NET GridView control and then do the binding just as you would normally with that control. The end result will look like this:

I've also included a bundle of the code and form for this sample as an attachment to this article. Have fun.

Relationship Property Names and Case

2009-03-27T18:38:00Z

In today's SalesLogix Web Developer class, we discussed an issue that someone in the class was having at runtime with a relationship that had a property that started with lower-case letters. Here are the details of that issue and the fix:

Scenario

Create a entity named "testProject" and then relate it to the Account entity. In the relationship, the Account will have a collection named "testProjects" (notice the property name starts lower case). You'll then use that relationship when you wire up your lookup on a form.

Problem

Every things builds fine, however at runtime you get an error saying "Could not find field '_TestProjects' in class Sage.SalesLogix.Entities.Account". Notice that the error refers to the property with an uppercase "T".

Solution

To fix this you just need to simply delete (or change) the relationship property to NOT start lower-case. Always name your relationship properties Proper-case, starting with an upper case letter always.

I don't know why this problem occurs. Seem that somewhere in the system an assumption is being made that the property name will be proper-cased (starting with an upper-case letter). However, I can tell you that you don't see the problem if you use the first letter upper-cased for the properties created in the relationship. Weird.

Setting the Default Sort for a DataGrid in SalesLogix Web REVISITED

2009-03-26T21:28:00Z

A while back I wrote an article on setting the sort for a DataGrid in SalesLogix Web at runtime. That solution worked great in SalesLogix 7.2. However, things changed in SalesLogix 7.5 so I thought it was time for an update to that original post. Let's see what changed and how to make it work again.

Take a look at the original article

In the original article, I mentioned that all this was possible because the SalesLogix DataGrid (Real class name SlxGridView) inherited from the ASP.NET GridView control. That hasn't changed. However, here is what has changed:

Change #1: Where you LoadAction code is located

The original "C# Snippet Action Item" has been deprecated. This is what was used before. Now there is a "Code Snippet Action Item" is what is used for code in LoadActions. The reason why this is significant is that the deprecated "C# Snippet Action Item" was placed inline in the SmartPart/ASCX file. So, you could rely on the fact that you could easily just reference controls on the form since the code also existed on the form. Now, with the new "Code Snippet Action Item", the code is compiled into a separate assembly, much like the code in business rules. You are passed a reference to the form - which is not really a reference to the SmartPart class itself, but instead via an object that implements IForm and IEntityForm.

Change #2: In LoadAction code, you no longer get a direct reference to the controls

This form object mentioned above exposes the controls on the form, however, not as the real control type, but as an adapter that wraps the control - only exposing certain things. For example, instead of exposing a reference to your SlxGridView (the datagrid), you get a reference to a faux-grid the implements IDataGridControl. This interface only provides access to a few handful of properties of the grid and the columns. The IDataGridControl implements IControl, which provides a few additional things, most notably, it provides a reference to the actual underlying control via an object property named NativeControl.

How do we make this work?

Using the IControl interface, you can take the control adapter you are passed in the LoadAction code and get to the native control. That is a simple task and then you'll be able to do anything you need with the native control reference. Here's some sample code that get's a reference to the native control and then does the sorting, just like before:

public static partial class RelatedAccountsEventHandlers
{
    public static void Step(IAccountTickets form,  EventArgs args)
    {
        System.Web.UI.WebControls.GridView grid = (System.Web.UI.WebControls.GridView)form.grdAccountTickets.NativeControl;  
        grid.Sort("ReceivedDate", SortDirection.Descending);
    }
}

Not so bad. The trick is knowing how to get to the underlying control from the adapter reference you are passed. One thing to note is that the code in the original article will still work in code in the now deprecated "C# Snippet Action Item", so if you've used the code prior to 7.5, it will still work in the C# action. However, for new systems you need to use the new code above.

Presentation of the Infusionsoft Outlook Integration at InfusionCon

2009-03-12T00:19:00Z

I was out at InfusionCon today, the annual user conference for Infusionsoft, for the public unveiling of the Infusionsoft Outlook Integration with Patrick Sullivan. I've been really excited for the Outlook integration to get into the hands of the Infusionsoft masses because, frankly, it is so completely cool. Patrick and I met up early to make sure all was working and ran through the demo several times.

Flash forward to the actual demo. Things started well. There was even loud applause and cheering. That's when things went downhill. Doh! Patrick's Outlook started to try to connect to Exchange and sync up folders via the wireless at the resort (something that it wasn't doing via Patrick's Verizon wireless that we were rehearsing with). The connection to his Exchange server just wasn't happening via the wireless connection from the resort so the result was that Outlook started freezing up while trying to sync the folders. Needless to say this made it, er, difficult for Patrick to continue demoing the integration. To be honest, it was disappointing to not get to show more than what we did, not because we were struggling through getting Outlook to behave, but because I think the Outlook integration rocks and I wanted for the Infusionsoft users to get to see all that it can do.

However, it was surprising that despite the difficulties in demoing the integration that there was so much positive feedback about the integration. I guess people saw enough before the problems started to know that they liked what they saw. When it comes to knowing how software and UI should work, Patrick is king. I think we've captured a completely unique yet intuitive experience in the integration. Best of all, this is just the beginning. If you've seen the integration or you're using it already, be prepared to have your socks knocked off throughout this year. There is some mind-blowing stuff that will be coming in the integration. It's great already, but we're going to be taking it up to 11 :-)

For those of you who have not yet seen it, you can see a short demo (the one that Patrick was intending to do at InfusionCon) here (be sure to click the "Full Size" button for full effect). However, keep in mind that Patrick is using a new untested build (not the same publically available version) so there are a couple of very quick nasties that pop up in the video.

View Patrick's Quick Video Demo of the Infusionsoft Outlook Integration
(Be sure to click the "Full Size" button)

All in all, it was great to be at InfusionCon with the guys from Infusionsoft. What a completely exciting company.

Determining if a User is a Member of a Team in SalesLogix Web

2009-02-04T21:13:00Z

Five years ago I wrote a post about how to determine if a user is a member of a team in SalesLogix LAN scripts that is still referred to today. I've been asked on occasion how one would go about doing the same in the SalesLogix Web platform, so I thought it was time for a follow up post. In this post I will demonstrate how to use a HQL query to create a reusable function in the SalesLogix Web platform to determine whether a user is a member of a specified team.

We will be creating this as a reusable method that we'll pass a User object to as well as the team name we want to check. Let's look at the code first and then we'll look at how to use it and where you might create this reusable code:

private bool IsUserOnTeam(Sage.Entity.Interfaces.IUser user, string team)
{
    using (NHibernate.ISession session = new Sage.Platform.Orm.SessionScopeWrapper())
    {
        return 0 < Convert.ToInt32(session.CreateQuery("select count(*) from OwnerRights r where r.Owner.OwnerTypeChar = :type and r.Owner.OwnerDescription = :teamname and r.User.Id = :accessid")
                   .SetAnsiString("type", Sage.SalesLogix.Security.StringEnum.GetStringValue(Sage.SalesLogix.Security.OwnerType.Team))
                   .SetAnsiString("teamname", team)
                   .SetAnsiString("accessid", user.Id.ToString())
                   .UniqueResult());
    }
}

The code above queries the SalesLogix entity model, looking at the OwnerRight entity specifically (this maps to the SECRIGHTS table in the database), and then limits that with conditions that the OwnerTypeChar property has the corresponding value for a team, the OwnerDescription has the correct team name, and to limit that to the OwnerRight entity instance where the UserId matches the Id of the User we pass in.

The code to use it might look something like this:

Sage.SalesLogix.Security.SLXUserService usersvc = (Sage.SalesLogix.Security.SLXUserService)Sage.Platform.Application.ApplicationContext.Current.Services.Get<Sage.Platform.Security.IUserService>();
Sage.Entity.Interfaces.IUser user = usersvc.GetUser();
 
if (IsUserOnTeam(user, "Midwest"))
{
    // user is on the Midwest team
}
else
{
    // user is NOT on the Midwest team
}

Now, where might we implement something like this? Personally, I would create this as a separate assembly in Visual Studio and plug in where needed. However, you could also implement this in a business rule as well. If you implemented this code in a business rule, you'll need to make sure the rule has the correct references. Otherwise it will produce an error when you build the web platform saying something about "are you sure you are not missing an assembly reference?".

By default, the rule will have references to the following:

Sage.Entity.Interfaces.dll
Sage.Form.Interfaces.dll
Sage.Platform.dll

For the code I outlined above, you'll also need to have references for:

NHibernate.dll
Sage.SalesLogix.Security.dll

I won't go into a whole lot of details now about how to add these references, I'll have those steps outlined in a future post. However, while in the rule editor, open the Property pane (F4), click the drop-down at the top of the Properties pane and select "Sage.Platform.Orm.Entities.CodeSnippetHeader". Then you'll see properties for the CodeSnippetHeader for your code. You can bring up the AssemblyReferences and add the ones I mention above to that dialog. Things should complile fine now and you could shorten the code a bit too since you can add usings for these namespaces and drop the fully-qualified names of the objects. Just make sure you don't try to add this rule to the User or other Security entities (See Accessing User and Security Entity Properties in SalesLogix Web)

One that thing I wanted to point out as well. The Owner object in Sage.SalesLogix.Security also has a similar function that will return a List<Owner> of all teams a specified user belongs to. That can come in handy as well. Here's a sample that you could add to a LoadAction on a form to display a list of the teams the current user belongs to in a multi-line TextBox on the form called QFTextBox (Note: for this code, you do need a Sage.SalesLogix.Security.User object, not just a Sage.Entity.Interfaces.IUser reference since the method specifically takes a User, not IUser, parameter):

Sage.SalesLogix.Security.SLXUserService usersvc = (Sage.SalesLogix.Security.SLXUserService)Sage.Platform.Application.ApplicationContext.Current.Services.Get<Sage.Platform.Security.IUserService>();
Sage.SalesLogix.Security.User user = usersvc.GetUser();
 
System.Collections.Generic.IList<Sage.SalesLogix.Security.Owner> teamlist = Sage.SalesLogix.Security.Owner.GetTeamsByUser(user);
 
string list = string.Empty;
foreach (Sage.SalesLogix.Security.Owner team in teamlist)
{
    list += team.OwnerDescription + "\r\n";
}
QFTextBox.Text = list;

This code could also be used to check if a member is on a given team. However, the implementation of the method used in the Owner object will also return all the data in the List as well (and if I would have just used that I couldn't have shown you the example using the HQL query).

Accessing User and Security Entity Properties in SalesLogix Web

2009-01-30T23:34:00Z

There are likely many cases in SalesLogix Web where you need to access properties on the User and Security related entities that are not included in the entity by default, meaning that there is no public property exposing the value. For example, the IsManager property on the User entity. A co-worker of mine ran into just this problem this week (See Retrieving the Manager in SalesLogix 7.5 Web)

The Problem

The root of the problem is that there are some often necessary properties on the User & Security related entities that are not included in the entity. See the image below:

Notice in the image above that the "Include" checkbox is not checked for the IsManager property on the User entity. What the Include value means is whether to include a public accessor property for this when the entity is built. So, you might think that checking this checkbox and doing a build will make it available to you at runtime. You build & deploy and get no errors. However, when you attempt to access the site you get a runtime error that states the following:

System.TypeLoadException: Method 'get_ManagerId' in type 'Sage.SalesLogix.Security.User' from assembly 'Sage.SalesLogix.Security, Version=7.5.0.1484, Culture=neutral, PublicKeyToken=null' does not have an implementation

Here is why you are getting this error; the "Packages" in the entity model are more than just for the sake of organization. The "SalesLogix Security Support" package of entities does not just exist to separate these entities from the others. Each package is built to a separate assembly. They can have different templates for code generation. They can also have properties to indicate whether they are built into an assebmly at build time at all. This is the case with the User and Security entities in the SalesLogix Security Support package. If you open the package itself and "Build Settings" tab you will see something different about this package.

You can see in the screenshot above that the SalesLogix Security Support package isn't event built when you build the web platform. However, it's interface is. When you check the Include checkbox on the IsManager property it is added to the interface. This is why you don't get a compile error when you use it in a code snippet because you're likely using the User entity via it's interface. However, since the assembly is not built as well there is no implementation for the IsManager property that now exists in the IUser interface, hence the "does not have an implementation" error. Checking the box for "Generate Assembly" on the package won't fix the problem. If you do, you'll get compile errors. These User and Security entities are available in the Application Architect so you can create relationships to them from other entities, however their implementation is quite different and the standard code generation templates will not account for all the extra things they do. So, what is the solution?

The Solution

Knowing why you're getting the errors and what the problem is does not exactly help in getting to these not-included values that you need from these entities. However, there is hope. When you access any entity in SalesLogix code, you're likely accessing the entity via it's interface (as you should). However, I mentioned above that there is a lot more to the implementation of the User and Security entities. That is where you'll find what you need.

Normally, you would access a User, such as the current user, like this:

Sage.SalesLogix.Security.SLXUserService usersvc = (Sage.SalesLogix.Security.SLXUserService)Sage.Platform.Application.ApplicationContext.Current.Services.Get<Sage.Platform.Security.IUserService>();
Sage.Entity.Interfaces.IUser user = usersvc.GetUser();

Note that you are accessing the User via the IUser interface. Now, the IUser interface is just a standard entity interface. Since the interface is being built when you do a "Build Web Platform" (note, the checkbox to build it's interface is checked for the package) it is a true representation of what you see in the Application Architect. However, there is quite a bit more to it's implementation found in the User class. Fire up Reflector and take a look at some of the things available in Sage.SalesLogix.Security.User:

Notice all the extra goodies there to use? For example, the Manager property, that returns a Manager object. The Manager class simply inherits from User, meaning that it has all the properties and methods that a User object has as well as a few more. To use this property, as well as the others in the User class, you just need to use the reference via the User class instead of via the IUser interface. Something like this:

// get the current user as a User (not IUser)
Sage.SalesLogix.Security.SLXUserService usersvc = (Sage.SalesLogix.Security.SLXUserService)Sage.Platform.Application.ApplicationContext.Current.Services.Get<Sage.Platform.Security.IUserService>();
Sage.SalesLogix.Security.User user = usersvc.GetUser();

// now get the user's Manager
Sage.SalesLogix.Security.Manager manager = user.Manager;
string manageremail = "Manager e-mail: " + manager.UserInfo.Email;

Note that the code is basically the same as when you accessed the User via the IUser interface. You just use the actual implementation class instead and you can get to what you need.

A Solution for All Cases?

This is not a solution for every case. There will without question be some properties that you just can't get to. The "last resort" solution to access these inaccessible properties is to go to the database. You can easily get a connection to the underlying database and use that to query for the value you're after. Here's an example:

// get the manager's e-mail address using a connection to the database
//
// Note: this is just for example purposes, instead of doing this
// use the user.Manager property available on Sage.SalesLogix.Security.User

string manageremail = string.Empty;
// get the DataService to get a connection string to the database
Sage.Platform.Data.IDataService datasvc = Sage.Platform.Application.ApplicationContext.Current.Services.Get<Sage.Platform.Data.IDataService>();
using (System.Data.OleDb.OleDbConnection conn = new System.Data.OleDb.OleDbConnection(datasvc.GetConnectionString()))
{
    conn.Open();
    using (System.Data.OleDb.OleDbCommand cmd = new System.Data.OleDb.OleDbCommand("select u1.email from userinfo u1 inner join usersecurity u2 on u1.userid = u2.managerid where u2.userid = '" + user.Id.ToString() + "'", conn))
    {
        object o = cmd.ExecuteScalar();
        if (o != null) manageremail = o.ToString();
    }
}

This is not an ideal solution, and isn't meant to be.In my opinion, accessing the database directly should absolutely be a last resort and avoided if possible. Why, the entity model is rich and complete in most cases. The majority of times I've seen someone go direct to the database it is more than likely because of a lack of knowledge of how to do something in the entity model, not because the entity model could not provide what was needed. Business rules that might be in place in the entity model will not apply to things you do in the database (unless they are implemented in Process Orchestration).

Ideally these properties in the implementation that are hidden by their absence in the interface would just be included in the interface. However, knowing that some of these things are there, and how to get to them, will definitely save you some headaches.

Programatically Adding a New Record in SalesLogix Web

2009-01-29T20:55:00Z

Something that is a common task in development, yet one that I get a lot of questions about, is how to programatically add a new record in SalesLogix Web using the entity model. This is an easy task, but unless you have some examples to learn from you might not know where to start. Let's take a look.

The EntityFactory is something you need to get familiar with. Get Reflector and dig around the Sage.Platform.dll to take a look. You'll use the EntityFactory to Create & Delete data. You can also use it to get a record by ID and to get a repository to query data in the entity model. Let's just take a look at using it to Create a new entity instance that we can save (which will add the new record to the database).

Scenario

Let's say we have an entity named Certification, which has a 1:M relationship to the Contact. We'll create a form under the contact where the user can choose a "certification" from a picklist and click an "add" button. We'll also put a DataGrid on the Form to display the certifications for the contact. When the "add" button is clicked we'll programatically create the certification record using the value the user selected in the picklist. Since the only selection to make is the certification, I like to do things like this instead of using a separate "add" form in a dialog that only contains a single control (the picklist). We've done away with the need to use an add dialog by just placing the picklist and add button controls right above the grid on the form itself.

The Code

The code that we'll execute on the Click of the add button would look as follows:

// make sure the user has selected a certification in the picklist
if (picklistCert.PickListValue != string.Empty)
{
    // get a reference to the current Contact
    Sage.Entity.Interfaces.IContact contact = this.BindingSource.Current as Sage.Entity.Interfaces.IContact;
    
    // programatically create a Certification and save it.
    // use the EntityFactory to create a new instance of the Certification entity
    Sage.Entity.Interfaces.ICertification certification = Sage.Platform.EntityFactory.Create<Sage.Entity.Interfaces.ICertification>(); 
    // now just set the properties & save
    certification.Contact = contact;
    certification.CertificationName = picklistCert.PickListValue;
    certification.Save();
    
    // add the certification to the contact's Certification collection. 
    // this is only needed to cause the grid bound to contact.Certifications to refresh
    contact.Certifications.Add(certification);
    
    picklistCert.PickListValue = string.Empty;
}
else
{
    // if the user clicked the add button without first choosing a certification display a message
    this.DialogService.ShowMessage("You must first select a certification to add. Please try again");    
}

You can see that the only tricky part is knowing how to create the new entity instance using the EntityFactory (I've bolded that line in the code above). Once you have that it is just a matter of setting the needed properties and saving it. Much easier than using a SQL INSERT statement or even adding a new record to an updateable ADO Recordset like how you would do this in the LAN client.

Last Chance to Register for SalesLogix Web Developer Training

2009-01-09T17:03:00Z

There is still time to register for my SalesLogix Web Developer training class starting this Monday. I am getting excited to start the class, we'll be covering how to develop a complete solution in the SalesLogix 7.5 Web platform. You can see the entire class detail here and register here.

This is why you should register for the class:

You'll learn what you need to know to develop complete solutions in SalesLogix Web
You'll learn it from someone who has developed many solutions for SalesLogix Web that are in production today
You'll end up with a working solution that you can use yourself or sell to customers (if you really follow along in the class in your own system)
You'll have a lot of fun :-)

I hope to see you in the class. It starts Monday and there are still seats available, but not many - so register quick.

Public SalesLogix Developer Classes Revamped

2008-10-27T23:51:00Z

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

2008-09-13T08:06:00Z

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)

2008-09-11T23:12:00Z

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

2008-09-02T22:08:00Z

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

2008-08-22T16:03:00Z

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

2008-07-28T23:54:00Z

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.