Kris Halsrud's Blog

Creating Pretty Prefixes and Suffixes in the SalesLogix web client

2010-03-17T10:16:00Z

In the SalesLogix web client you may run across a reason you need to generate a “Pretty Key”. This is what the SalesLogix Ticket Number is. This key is a combination of a Pretty Prefix and a Pretty Suffix. The Prefix is an equivalent to a system’s site code and the Suffix is a numerical equivalent to a primary table ID.

To generate these you can simply call the functions in the Sage.SalesLogix.System.dll for each. Each function expects an input of the Primary ID of the record to generate a key based on, like this:

Sage.SalesLogix.PrettyKey.GetPrettyKeyPrefix(account.Id.ToString());
Sage.SalesLogix.PrettyKey.GetPrettyKeySuffix(account.Id.ToString());

Be aware that the Sage.SalesLogix.System.dll is not a default assembly for C# Code Snippets so you may need to add it as a reference.

Editing tables in SQL 2008

2010-03-16T10:58:00Z

I recently ran into an issue when trying to edit a SalesLogix table in the SQL Management Studio 2008. I was trying to increase the length of a field while in a table’s design mode. When I went to save my change I received this error:

Saving changes is not permitted. The changes you have made require the following tables to be dropped and re-created. You have either made changes to a table that can’t be re-created or enabled the option Prevent saving changes that require the table to be re-created.

Now I have done this countless times in the past and wasnt sure what was going on but the last part of the error message pointed me in the direction I needed. Turns out that a default option for the SQL 2008 management console prevents edits to tables like I wanted. After a little digging I found where to turn this off.

In the Management Console, click the Tools drop down menu, then Options.

This will open a dialog. Expand out the Designers node in the left side tree, then click the Table and Database Designers. That will show options to the right. Clear the checkbox “Prevent saving changes that require table re-creation”.

Click OK and that is it!

Adding an assembly reference to code files in the SalesLogix Application Architect

2010-03-15T18:22:00Z

Often when adding custom code to SalesLogix you need to reference Assemblies that are not included by default in Code Snippets or action items. This problem will often manifest itself with an error when building like “The type or namespace name 'Data' does not exist in the namespace 'System' (are you missing an assembly reference)”

This article will show you how to add an assembly reference to your code. If you look at either a Business Rule/Event or a Code Snippet Action item, both have a Reference Assemblies property. In the code editor within Application Architect you will see comments at the top of the code that show the included referenced assemblies like so:

So how does one add a referenced assembly? Well it is fairly easy, though do to a glitch in the interface the actual process is kind of hidden. With the code page visible, open the properties window. In the drop down at the top of the property window you should see Sage.Platform.Entities.Orm.Entities.CodeSnippetHeader. If you choose this then you should see an AssembliesReference collection. This is the avenue for adding assembly references.

On some version of the Application Architect, the Sage.Platform.Entities.Orm.Entities.CodeSnippetHeader is not visible to be selected in the drop down. To get it to appear, you need to do the following:

Click the CodeSnippet property in the properties window (should be the first one)
Click into the Code itself.
Click on the drop down in the properties window. You should now see the choice Sage.Platform.Entities.Orm.Entities.CodeSnippetHeader.

Once you can correctly see the property window, click the Assembly References Collection property. (There should be an ellipse to choose.)

This will open up the Assembly Reference dialog. It should show you what the default assemblies that are included in every event/snippet are.

If you click Add, you can add a new reference. You will need to enter the AssemblyName at a minimum. This should be the full file name of the assembly (i.e. System.Data.dll). If the assembly is part of the .Net global assembly cache you should not need to enter a hint path. If the assembly is not in the GAC, you will need to add the hint path which is the location the assembly is physically located so it can be accessed to validate during the build. I would recommend using the base build path’s assemblies sub folder. This requires copying your assembly into that location so it is available. See this post for some more info on where assemblies need to be to build successfully. The HintPath should be the full path, plus the full file name.

While you are defining your assembly reference you may receive errors. Just click OK. They are basically just a warning that the assmbly reference isn’t fully defined (which it won’t be until you are done defining). As long as you can build successfully after you add your reference you should be fine.

Launching a report from a button in the SalesLogix web client

2010-03-12T12:49:00Z

As Jason mentioned in his article here, starting in SalesLogix 7.5.1, Sage released an undocumented Reporting enhancement that allowed for interacting with the SalesLogix web reporting Server. The SalesLogix 7.5.2 release had this API enhancement built in, however little documentation exists and now standard samples are used in the web client.

Hopefully this article will help out those who are trying to figure this out.

The core of the reporting functionality is contained in a standard javascript file “ShowReportUtil.js” that interacts with the built in SalesLogix web reporting functionality. In order to use any of the functions in the above mentioned java script files you can just add a client click event to a control (like a button), a single line of code like:

ShowReportByName('Contact:Contact Detail');

Now lets look at the javascript file. The file can be found in the Application Architect under Portal Manager…Sage SalesLogix…Support Files…jscript.

If you examine the java script file you can see the various exposed methods available they include:

ShowReport(ReportNameOrId, EntityTableName, EntityId) - Shows the report defined by ReportNameOrId using the EntityTableName and EntityId values.
ShowReportByName(ReportName) - Displays a report by FAMILY:NAME. The report should be based on the main table associated with the current view.
ShowReportById(ReportId) - Displays a report by PLUGIN.PLUGINID. The report should be based on the main table associated with the current view.
GetReportId(S) - Returns the PLUGIN.PLUGINID associated with the report defined by the S parameter (In the FAMILY:NAME format).
GetCurrentReport() - Returns the report associated with the current view, if any (Outputs in the FAMILY:NAME format).
PopulateGlobals(ReportId, EntityTableName, EntityId) - Populates the global report variables used in ShowReport.ascx (in Sage.SalesLogix.Client.Reports.Helper.dll).
ShowDefaultReport() - Displays the default report for the current view and entity, if a report has been associated with the view. Defaults are defined at the top of the java script file.

Hiding Opportunities in the SalesLogix web client

2010-03-10T23:38:00Z

Occasionally we have clients who do not use the Opportunity components of the SalesLogix web client. They have asked us to remove the Opportunity visibility within the web client. Since this is not a common occurrence, I usually end up having to go back and remember where all the places are I need to touch. I decided to write this article for my own reference and to help others who may be looking to do this.

The SalesLogix web architecture makes hiding opportunities pretty easy. most of the configuration involves simply removing web parts from various portal pages, however there are a couple of smart parts you need to touch.

Lets start with the easy ones, the portal items to remove:

On the Account Detail Page, remove the web parts “AccountOpportunities” and “AccountResellerOpportunities (Custom)”

On the Contact Detail Page, remove the web part “ContactOpportunities”

On the main Sage SalesLogix portal, click the Navigation tab and under Navigation Bar, remove the item under “Sales” called “Opportunities”

On the main Sage SalesLogix portal, click the Navigation tab and under Toolbar Menus, remove the item under “New” called “Opportunity…”

On the Options Page, remove the web parts “OpportunitiesOptionsPage (Custom)” and “DefaultOpportunityProduct (Custom)”

Next we need to modify a few Activity and History forms. Most of the forms are custom smart parts but there is one History Quickform.

Under Entity Model…Packages…SalesLogix Activity Support…History…Forms, open History Details. Bring up the Properties for the Opportunity Lookup and set the Visible property = false. Save the Quick form.
Under the Portal Manager…Sage SalesLogix…Support Files…Smart Parts…Activity open ActivityDetails.ascx. Look for both the Opportunity label control and the Opportunity lookup control in the markup. Add the attribute Visible=”false” to both of these controls.
Under the Portal Manager…Sage SalesLogix…Support Files…Smart Parts…Activity open CompleteActivity.ascx. Look for both the Opportunity label control and the Opportunity lookup control in the markup. Add the attribute Visible=”false” to both of these controls.
Under the Portal Manager…Sage SalesLogix…Support Files…Smart Parts…Activity open ScheduleCompleteActivity.ascx. Look for both the Opportunity label control and the Opportunity lookup control in the markup. Add the attribute Visible=”false” to both of these controls.

That is all there is to it. Opportunities no longer visible in the web client.

Using ICriteria and Not to exclude records in SalesLogix

2010-03-04T16:39:00Z

In SalesLogix you can use the Sage.Platform.Repository.ICriteria class to query the entity model using standard ICriteria. One thing I have been asked in the past is how do you exclude certain conditions? A common example might be show me all of the non-closed tickets for a contact, where being closed is denoted by a status=”Closed”. In this scenario you only want a condition similar to status<>’closed’. This can be done using the .Not method which accepts as an input a standard parameter to exclude. Lets take a look at the code:

RepositoryHelper<Sage.Entity.Interfaces.ITicket> repository = EntityFactory.GetRepositoryHelper<Sage.Entity.Interfaces.ITicket>();

Sage.Platform.Repository.ICriteria criteria = repository.CreateCriteria();
criteria.Add(repository.EF.Eq("Contact.Id", contact.Id.ToString()));
criteria.Add(repository.EF.Not(repository.EF.Eq("StatusCode", "Closed")));
criteria.AddOrder(repository.EF.Desc("CreateDate"));

result = criteria.List<Sage.Entity.Interfaces.ITicket>();

You can see the entity factory EF.Not used above which has passed in a EF.Eq condition looking for “Closed“ statuses. Now in this scenario I am using it assumes that StatusCode is storing “Closed” as text and not as the corresponding picklistid, which is not the standard OOTB SalesLogix behavior, but it should never the less demonstrate how to use the Not method to exclude a condition from your query result.

SalesLogix web client error: System.IndexOutOfRangeException: Index was outside the bounds of the array

2010-02-24T11:06:00Z

I recently ran into this error on a client’s system when users logged into the SalesLogix client and navigated to a recently updated page. The administrator did not encounter the same issue when navigating to the same page. Since I knew no log-in specific customizations were in play, I knew it had to be an issue beyond the web site. The SalesLogix provider acts differently for users than it does for the admin. Specifically when a user connects through the provider the provider adds on record level and field level security. Knowing this I figured that the field level security was messed up.

When you install a new database field into an existing table through a SalesLogix bundle, SalesLogix does not always correctly update the field level security information of the table to include the new field. This results in a mismatch between the number of fields the system sees in the database versus the number of fields the system detects for field security. This mismatch was the root cause of the specific error mentioned in this post title. Now it is very easy to fix the mismatch of database and field level security.

To fix the mismatch simply log into the SalesLogix Administrator as admin. Go to Manage…Field Level Security. When the Manage dialog comes up you just need to click the OK button. When this is clicked the Field Level Security information is re-written using the current database level definitions. You do not even need to actually modify a field level profile. Of course, it is a good idea to ensure that the new fields have the proper field level security levels inside each security profile.

I always recommend that after installing a bundle the database changes you open and close the Manage Field Level Security dialog to avoid these kinds of problems.

Properly adding child records using the SalesLogix entity model

2010-02-17T11:54:00Z

The SalesLogix entity model offers a really great way of working with data in SalesLogix and letting the system establish all of the links for you- as long as you know what you are doing.

One of the really great things that you can do is to add child entities to a parent, even if the parent is not yet in the database. This is especially helpful if you need to create child records while still on an insert screen, like when inserting a contact being able to add multiple history records for the contact, even before the contact is created.

If we were working in the LAN you would have the problem of not having the contact in the database and available for you to get its ID so that you could use the ID when inserting child records. Normally in the LAN client you would need to generate an ID and then set the ContactID value with that before saving the record. In this way you forced the system to use your record ID rather than wait for the record to be committed. Each child record you added you would need to pass the ContactID and properly set the foreign key field so that the child records were linked to the opportunity. And if the user later decided not to actually insert the contact, you had to remember to go in and delete any child records you may have inserted already. In short, a big headache.

With the entity model you simple tell the system you want to add a new child entity into the parent entity’s collection. The system automatically worries about if it exists yet and how to actually do the linking for you.

Lets take look at the proper way of doing this.

First of all, lets talk about one way of doing it that should not be used. Using the entity Save() method. The reason that this should not be used is because calling Save() on a child record will actually roll-up and save all parent entities and all child entities of the parent. This could lead to premature saving that could bypass important business validation logic. Lets look at one example.

Say we have the insert Contact screen and when the Contact Status is set to a certain value we want to create some activity record. To do so we could use code like:

Sage.Entity.Interfaces.IContact contact = this.BindingSource.Current as Sage.Entity.Interfaces.IContact
Sage.Entity.Interfaces.IActivity act = Sage.Platform.EntityFactory.Create<Sage.Entity.Interfaces.IActivity>();
act.AccountId = contact.Account.Id.ToString();
act.AccountName = contact.Account.AccountName;
act.ContactId = contact.Id.ToString();
act.Description = "Something"
...
act.Save()

Now the problem with this code is three fold.

We do not yet have the contact.Id property filled in. This is only generated after the Contact entity has been saved and not during the insertion process. If the Activity entity had a entity relationship property called Contact which represented Sage.Entity.Interfaces.IContact, we could instead pass in act.Contact = contact, but again this is not the best approach because of the next point.
Calling the act.Save() will actually save the new Activity record but also save it’s parent, the new Contact we are inserting. At this point maybe the contact is not fully completed. We do not want to trigger the parent Save method prematurely. For this reason, lets look at the right way of doing it
Using the Save() method like this also means you would need to remove this saved record, should the user decide to not complete the insertion of the new contact. However that would also be complicated since by calling the child’s Save() method you have already actually saved the Contact record!

The proper way of adding children to an entity is by inserting records into the parents collection. So instead of the code above having

act.Save()

at the end, we would instead want to add the new Activity record to the Contacts, Activity collection like so:

contact.Activities.Add(act);

Using this method simply adds the Activity into a temporary collection that will be actually added to the database once the user chooses to insert the contact. When the contact.Save() method is eventually called it will save all of the parent data and any data residing in child collections. Conversely if the user cancels the insertion all of the pending child collections are flushed automatically.

Again, the Entity Model, if understood, simplifies how you do things in the SalesLogix web client. You no longer need to worry about if your parent record exists, or how to correctly bind records together. Using the Entity Model correctly takes care of these things for you.

Setting both the Text and Value properties of Items in the SalesLogix ComboBox control

2010-02-11T17:21:00Z

SalesLogix web has a “ComboBox” control which is actually rendered on the deployed page as an ASP ListBox control. In the Application Architect you can see the control has two properties for Value and Text. The value

One would assume SalesLogix would have a built in property exposed to allow you to add items to the ComboBox and to set the Text and Value portions of said items, and they do, sort of. If you go to a code editor in the Application Architect and start looking at the attributes and methods exposed for the ComboBox you will see an Items collection with an Add method. Looks like we have it.

As the code help shows the add method takes two parameters on for the text string and one for the value string. The only problem with this is if you do so, something like:

cboProblem.Items.Add(“Some text”,”ID123”);

You will get an error when you visit the page on the web site along the lines of:

A smart part associated with this page has failed to load: c:\Inetpub\wwwroot\site\SLXClient\SmartParts\Ticket\TicketCall.ascx(124): error CS1501: No overload for method 'Add' takes '2' arguments

If you pass in instead just:

cboProblem.Items.Add(“some text”);

This will work, however both the text and value properties of the list item will be “Some Text”. Not good if you need to know a specific ID value of a list item chosen.

So what gives? Well it turns out what you actually need to pass into the Add method is a ListItem. The list item can then have two values, one for text and one for value. So the proper format of the add command would be:

cboProblem.Items.Add( new System.Web.UI.WebControls.ListItem(“Some text”,”ID123”));

Now that you have populated the list with your various entries and defined the text and value portions of the items you can retrieve them like so:

//get selected item's value
string val = cboProblem.Items[cboProblem.SelectedIndex].Value
//get selected item's text
string disp = cboProblem.Items[cboProblem.SelectedIndex].Text

Getting a user time stamp in the SalesLogix Web client

2010-02-10T12:07:00Z

The SalesLogix web client has a couple of locations that they have a button to add a user time stamp within a memo field. For instance, on the standard Ticket Extended Details, on the Problem and Solution fields. If you look at these buttons they are actually executing a Sage Business rule called “AddTicketSolutionTimeStamp” or “AddTicketProblemTimeStamp”. These business rules actually prefixes the data already in the solution or problem with a user and date time stamp in the format of “Lee Hogan 2/9/2010 12:40:18 PM (Central Standard Time)”.

This time stamp would be a useful feature to use elsewhere but since this is built into a standard Sage business rule on the Ticket you can’t simply call these business rules. However, if we dig into one of the business rule using reflector we can see that if utilizes the Sage.SalesLogix.BusinessRule class in the Business Rule assembly to actually get the time stamp:

The fully qualified path to the rule is “Sage.SalesLogix.BusinessRules.BusinessRuleHelper.AddUserDateTimeStamp()”

Luckily this Business Rule Helper is an exposed method. Sage has a bad habit of not publically exposing some helpful rules but in this case we have lucked out. So with this method available to us we can use it somewhere to add our own user time stamp like:

Sage.Entity.Interfaces.IWidget widget = this.BindingSounrce.Current as Sage.Entity.Interfaces.IWidget;
if(widget.Notes != null) widget.Notes = Sage.SalesLogix.BusinessRule.BusinessRulesHelper.AddUserDateTimeStamp() + System.Environment.NewLine + widget.Notes;

Simple

SalesLogix 7.5.2 Hot Fix 1 – the Dependency Lookup is still broken

2010-01-27T22:04:05Z

SalesLogix released hotfix 1 for SalesLogix 7.5.2. One of the published resolutions of the hot fix was a modification to the dependency lookup

to fix defect 1-72412 “Editing ACI values on the ticket causes the ACI view to freeze”. This fix entailed a new version of the SalesLogix web control assembly. I had been hoping that Sage would also sneak in a serious design flaw with the dependency lookup that prevents you from seeing what the user has set the value to. For instance on a ticket If a ticket has an Area=A Category=B and Issue=C and the user changes this so the Area=A the Category=Y and the Issue=Z, you would expect the exposed OnChange event of the dependency lookup to return that the new values are A, Y, and Z respectively. However the on change event apparently runs too soon and still returns A, B, and C. This is really lame and makes the dependency lookups unusable for logic evaluation purposes .

I guess I will keep my fingers crossed for Hot Fix 2.

Clearing user default settings in the SalesLogix web client

2010-01-13T11:12:00Z

Each user of the SalesLogix web client can define various user based settings while they are using the SalesLogix web client. Things such as splitter height, visible tabs, open tabs, etc are all stored per user. Sometimes these settings block other changes that you would like to force out administratively. For instance what if you decide you want to set the tab order on the account page to be a particular order? Well for users who have never logged in, the next time they log in they will see this change. however, users who have already used the system will not see the change. This is because the user’s previous tab definitions have already been defined and stored. These individual user preferences take precedence over the default settings.

The settings are actually stored in the SalesLogix database in the VIRTUALFILESYSTEM table. This is so that regardless of what computer the user logs into the web client with, the settings will carry across. Now the VIRTUALFILESYSTEM actually contains pretty much everything that is the SalesLogix web client, including all of the entity definitions, screens, code, etc.

Because of this and because it is just smart, I need to pause here and say: “PROCEED AT YOUR OWN RISK. MODIFYING THE DATABASE AS DERSCRIBED BELOW CAN BE POTENTIALLY HARMFUL IF YOU DO NOT KNOW WHAT YOU ARE DOING. PROCEED ONLY IF YOU UNDERSTAND WHAT YOU ARE DOING AND ALWAYS TRY THIS SORT OF THING IN A TEST SYSTEM FIRST”.

OK Now that this disclaimer is out of the way, you can find all of your users default settings stored in the VirtualFileSystem by running a query similar to:

Select * from VIRTUALFILESYSTEM where modifyuser = ‘{USERNAME}’ and itemname<>’{USERNAME}’

The query above needs to be updated to have {USERNAME} changed to the SalesLogix username like “lee” for Lee Hogan.

Now to clear all of the user settings you can run a query like:

Delete from VIRTUALFILESYSTEM where modifyuser = ‘{USERNAME}’ and itemname<>’{USERNAME}’

After executing the script you would need to do an IIS reset to clear the old settings from the IIS cache.

How to make the SalesLogix web insert Contact/Account screen work like the LAN version for Account fields being editable

2010-01-07T17:04:00Z

In the SalesLogix web client the insert Account Contact screen behaves differently than the LAN version in that you can modify the Account level fields when you select an existing Account to use. I was recently asked how to make it work like the LAN client so that the Account fields are not editable.

When I looked at the form (which is a custom Contact smart part called InsertContact.aspx) I noticed that on the Account lookup control there is code in there to do this, however it does not appear to work correctly. In the code you can see it has something like this:

if ((account != null) && (contact != null))
    {
        txtContactAccountName.Enabled = false;
        adrAccountAddress.Enabled = false;
        phnAccountMainPhone.Enabled = false;
        phnAccountFax.Enabled = false;
        pklAccountType.Enabled = false;
        pklAccountSubType.Enabled = false;
        pklAccountStatus.Enabled = false;
        pklAccountIndustry.Enabled = false;
        txtAccountBusinessDescription.Enabled = false;
        usrAccountManager.Enabled = false;
        ownAccountOwner.Enabled = false;

I found that by changing it to read like this instead, it worked:

if ((account != null) && (contact != null))
{
    txtContactAccountName.ReadOnly = true;
    adrAccountAddress.ReadOnly = true;
    phnAccountMainPhone.ReadOnly = true;
    phnAccountFax.ReadOnly = true;
    pklAccountType.ReadOnly = true;
    pklAccountSubType.ReadOnly = true;
    pklAccountStatus.ReadOnly = true;
    pklAccountIndustry.ReadOnly = true;
    txtAccountBusinessDescription.ReadOnly = true;
    usrAccountManager.ReadOnly = true;
    ownAccountOwner.ReadOnly = true;

Go figure. I guess the enable property is not quite functional.

SalesLogix 7.5.2 Web - Invalid Index X for this OleDBParameterCollection Error

2010-01-06T15:32:00Z

I recently ran into an error on an upgraded SalesLogix 7.5.2 web client when attempting to save changes to an entity using the standard entity.Save() method. The error looked like:

I found that the cause of the problem was that for some business logic reasoning we had been setting an entity property’s relationship ID via code on the result of a lookup control’s change action. Let me explain that a little better. The entity ( I will call Widgets) has a relationship to another entity. That relationship is expressed with a property called Widget.Role. The entity itself has a property called Widget.RoleId which is the field where the ID is stored that actually creates the relationship to the other entity. Hopefully that makes sense.

Now when you use a lookup control, what happens when you perform a lookup to an entity, SalesLogix automatically creates the relationship (Widget.Role) but does not populate the ID field (Widget.RoleId) until after the save event.

Back to my scenario, we had been using in code calls to Widget.RoleId to get values. Now this worked fine for existing entities with the relationships established but when inserting a new Widget the RoleId property was empty, even after using the lookup control to populate it. For this reason we had mistakenly added code to the lookup change event to set Widget.RoleID = Widget.Role.Id.

I say mistakenly, because this led to the error I mentioned above. Apparently SalesLogix, when saving a record attempts to identify how many fields have changed on the entity in order to issue the underlying database commands. By us having manually updated both the Widget.Role (via the lookup) and Widget.RoleID (via the code) the system saw 2 fields having been updated even though it was in fact an update to really only one field. This caused the creation of the array used by the underlying database update to have an invalid array.

We resolved this by changing our code from checking the Widget.RoleId property to checking the SalesLogix generated Widget.Role.Id property and all was back to blissfulness.

KnowledgeSync has updated their user manual

2009-12-22T13:08:39Z

Anyone that has worked with the KnowledgeSync manual in the past knows that it is a massive document of over 500 pages. Well, VineyardSoft has decided to do a re-write of the manual and has condensed it down while at the same time updating documentation with newer operating systems. You can download the new document here.

Error deploying a SalesLogix 7.5.2 web client portal

2009-12-21T11:29:00Z

Recently I upgraded a SalesLogix web environment from 7.5.1 to 7.5.2. Once I had done so when I tried to deploy I received the following error:

ERROR - The following project item, '\Portal\SlxClient\ChildPages\Access\Access.page.xml' failed validation.

The error referenced a custom page called Access in the system. I opened up that page and everything looked fine. I have had experiences like this where if something errors in 7.5.2, simply modifying it trivially (like adding a space to a code file) and re-saving fixed the problem. When I tried that on this scenario I received an error when attempting to save:

Apparently the 7.5.2 does some additional validations that 7.5.1 does not. This particular page it turns out did not have an Entity defined for it under the Page’s Page Property collection. Once I added that, I could save it. After saving I was able to deploy.

If you run into an error during deployment, check out the page it references. Make sure it is properly configured. Again this kind of validation in new in SalesLogix 7.5.2 web.

Sage SalesLogix web Build error: The name 'XXX' does not exist in the current context

2009-12-17T19:08:28Z

I have found what appears to be a bug in 7.5.2 and the handling of external assemblies referenced for use in SalesLogix code, like business rules, events, custom properties, etc. I had a system that had multiple external assemblies handling some global business rules that were shared across multiple entities in the SalesLogix web portal. After upgrading to 7.5.2 I could no longer do a full build on the system. I would get the following error:

ERROR - C:\Users\bobo\AppData\Roaming\Sage\Platform\Output\Sage.SnippetLibrary.CSharp\src\Sage.SnippetLibrary.CSharp.@.296d53c4-46bb-4baa-a4f5-44f57dec9720.codesnippet.cs(47,13):The name 'XXX' does not exist in the current context

The rule that uses the assembly does have a reference to the assembly and worked fine in 7.5.1. I tried removing the reference and re-adding in the business rule. In the actual code file, the intellisense in the Application Architect code editor detects the assembly and its various classes and methods. However every rule, event, custom property, etc. that uses this external assembly failed with the same error.

I initially realized my external assemblies all had references to the old 7.5.1 Sage references. I recompiled the assembly using the new 7.5.2 Sage dlls as references within it. This did not help but is an important thing to remember you have to do.

I also tried adding a reference in the codesnippet.xml file (On Win7 this is @ C:\ProgramData\Sage\Platform\Configuration\Global) which I understand is supposed to act like a global assembly reference for all files on the site. This didn't work either.

I was at my wits end. By chance I happened to see a warning message that had occurred way up in my build. That led me to the solution I needed.

As I mentioned, I think this should be considered a bug. It is really stupid but easy to remedy.

I think that before 7.5.2 when you had external assemblies referenced in code snippets, or whatnot, that when you built, it used the specified reference path to do the build (logical). Apparently in 7.5.2, while you still need to add the reference to the assemblies in the code files, it apparently does not use that path during the build, or at least all parts of the build.

The simple fix is: any external assemblies need to exist in the SalesLogix\SalesLogix directory (C:\Program Files\SalesLogix\SalesLogix"), regardless of where each code file says the reference location is. I figured this out because I had a warning message earlier on that said:

Unable to locate assembly reference FX.Gen.dll in assemblies or C:\Program Files\SalesLogix\.

Now, I don't know why this message says this because my assembly is in my output folder's "assemblies" directory (that is where I specified it was in my code file references). Regardless, simply copy the file to the directory makes it all sing.

This whole assembly reference area seems REALLY kludge to me. It gets exponentially harder to manage when you are talking about multiple assemblies being added by multiple developers on different computers with different OS and centrally shared using Git. I hope Sage does something to help with this because I can see that this will be a nightmare for system maintenance and upgrades.

SalesLogix 7.5.2 change to the IOwner interface

2009-12-17T15:09:43Z

I have not found any official reference to this change anyplace: prior to 7.5.2 the Sage.Entity.Interfaces.IOwner entity contained a RightsCollection collection of user rights (Sage.Entity.Interfaces.IOwnerRights which represents the database table SECRIGHTS). In 7.5.2 this has changed to now just be called Rights. If you have any code that was using the previous property name “RightsCollection” you will need to update them when you upgrade to 7.5.2.

The SalesLogix bundlediff.exe utility for SalesLogix 7.5.2

2009-12-16T19:52:00Z

During the SalesLogix upgrade from a previous version of the SalesLogix web client ot 7.5.2 one of the procedures is to create a manifest bundle of all of you customizations. SalesLogix has now provided a utility to help compare what from your custom manifest has changed in SalesLogix 7.5.2.

Lest say that I am on 7.5.1 and want to bundle up all of my changes. The first step would be to create a workspace VFS that contained the base 7.5.1 VFS. Make sure this base VFS also consists of any hot fixes matching your current version. From within Application Architect you can then go to your custom VFS and create a bundle based on project differences. Select to compare to the base 7.5.1 workspace you set up and the resulting bundle should be a comprehensive list of all the items that have changed from the base 7.5.1 system.

In the SalesLogix 7.5.2 service pack, when you extract it you will find a “Project Differences” folder. In this folder are bundle manifests showing what has changed from one level to the next. Since my example I am upgrading from 7.5.1 to 7.5.2 I would be interested in the file “Sage SalesLogix 7.5.1 to 7.5.2 Model Changes.zip”.

Now armed with these two manifests, the first thing to do is copy them to a short path on a computer that is on the 7.5.2 level. I would recommend something simple like C:\SLX752. For ease of use I would copy these manifest into this directory. To make it even easier to work with I would also rename the manifest to something short like “Custom.zip” and “SLX.zip”. The reason for this is because we need to type this into a command prompt coming up and working with short names is nice. You can keep a copy of these files with their original names to be used for later purposes.

Now with the files here you can run the bundlediff.exe that is part of the SalesLogix 7.5.2 installation. This is a command line based utility that requires you to pass in the parameters you need. In typical Sage-like fashion there is not a lot of documentation but basically this utility lets you compare two bundle manifests and see what common elements are contained in them.

The first thing you need to do is open a command line prompt (Start…Run “cmd”). Then you will need to navigate the prompt to the SalesLogix installation directory or type out the full path to the utility. Once you are in the SalesLogix directory you can then execute the bundlediff.exe. This utility requires you specify two bundles and a compare option switch. By default the utility outputs to the console but you can add a switch to output it to a file.

Lets take a look at the command line:

bundlediff.exe /Bundle1:"C:\SLX752\Custom.zip" /Bundle2:"C:\SLX752\SLX.zip" /DiffOption:Common >"C:\SLX752\Log.txt"

You must specify each bundle by calling /Bundle1 or /Bundle2 followed by a colon and then the path to the manifest. The other switch is /DiffOption which also follows the format of the switch, a colon, and then the option to choose. Here are your choices:

AllItems - lists every item in both bundles. This is a flat list of bundle contents without differencing. You can use this to see a complete list of what items Sage changed in the release.
Common - lists the bundle items that exist in both bundles. These are the items that you will have to act on (ignore or merge) when you apply your customization bundle.
Bundle1OnlyItems - lists items that exist in bundle 1 but not in bundle 2.
Bundle2OnlyItems - lists items that exist in bundle 2 but not in bundle 1.
CommonAndExclusive - lists all items using the Common, Bundle1OnlyItems, and Bundle2OnlyItems parameters.

The last part of the command line is the switch to output the contents from the console window to a file. This requires the > symbol followed by the path to the file to log to. I believe the log file must already exist, the utility will not create one so you will need to create an empty text file to use.By aware that all of the command line switches and options are case-sensitive

The end result is a log that looks something like this:

Validating command line arguments.
The following are bundle items that exist in both bundles.
\Entity Model\SalesLogix Application Entities\Account\QuickForms\AccountContacts.main.quickform.xml
\Entity Model\SalesLogix Application Entities\Account\QuickForms\AccountTickets.main.quickform.xml

Hopefully this helps explain the SalesLogix bundlediff utility a little bit. While this is a nice little feature to have the same type of comparison could be done using other file and directory comparison tools that are widely available for free, like DiffMerge or commercial products like Beyond Compare

Unable to open 7.5.2 Application Architect after upgrading from 7.5.1

2009-12-15T22:45:00Z

Not sure under what circumstances this will occur but I just ran into this on a Windows 7 64bit computer and thought I would post. After upgrading the computer from a 7.5.1 installation to 7.5.2 I was unable to open the Application architect. An error was displayed:

A module declared a dependency on another module which is not declared to be loaded; Missing module(s):

Sage.Platform.Extensibility.PlatformModule,

Sage.Platform.Orm.CodeGen.CodeGenerationModule (Sage.Platform.Application)

The solution to this problem was to uninstall the SalesLogix Admin tools and then reinstall them again (7.5.0) and then re-apply the service pack 7.5.2. After doing this everything seemed to work fine.

Follow up to selecting a SalesLogix gridview Row ID

2009-12-04T19:38:37Z

In my previous post, I mentioned how to get the selected ID of a gridview’s row when you click the row. Since then I have found that sometimes SalesLogix will implement an extra DataKey in the grid when it is deployed as a quick form. (For instance, if you specify the grid’s DataKeyNames = “Id”, when it deploys you will actually see the grids DataKeyNames are “InstanceId, Id” When you call the code I had mentioned before:

string historyid = grdSystemNotes.SelectedDataKey.Value.ToString();

The system would actually return the InstanceId DataKey since that is the first specified. The InstanceId is a GUID based Id for the rendered HTML grid and does no good for us wanting to get the row’s ID. The more sure-fire way of getting our desired DataKey “Id” is by using code like this:

string noteid = grdActivities.DataKeys[grdActivities.SelectedIndex].Values["Id"].ToString();

Enforcing numeric input on a SalesLogix 7.5.1 quick form text control

2009-12-02T19:39:40Z

SalesLogix has a couple of numeric based custom text controls including currency, and numeric. One of the things you will find is that using these controls gives the user a slightly different experience based on the custom control chosen. One of the big differences is that the currency control enforces numeric input once the user leaves the field where the numeric control has no such validation.

Typically you would control this type of client side behavior in JavaScript or jQuery. Unfortunately SalesLogix does not allow direct access to specifying client side events on most controls at design-time. There is a way of doing this however by adding attributes to the control when the page loads using the Control’s Attribute.Add method.

Now before I get to how to do that lets look at a sample of JavaScript that would restrict user input to only numeric values (and delete and backspace)

var key = window.event.keyCode;
if ( (key > 47 && key < 58) || key == 8 || key == 127)
return; //It is valid so don't do anything
else
window.event.returnValue = null; //Don't allow the input

Now how to add this so that the quick form binds our JavaScript to our control? As mentioned, using the Attribute.Add method. Shown here is how you could do this using a C# Snippet Action Item “(Obsolete)” on a form Load event:

myTextBox.Attributes.Add("onkeypress",
"BLOCKED SCRIPT var key = window.event.keyCode; if ( (key > 47 && key < 58) || key == 8 || key == 127) return; else window.event.returnValue = null;");

The Attributes.Add is called for your user control. The first parameter is to identify what attribute you are adding. In our case we want to add code to the key press event. The second attribute is the actual JavaScript code. Add this to an OnLoad event for you page and you have numeric input validation.

How to invoke a web lookup control’s popup event in the SalesLogix web client

2009-11-27T21:44:12Z

One of the things that is often asked is how can you call a certain lookup’s “Popup event” from code in the SalesLogix web client. The SalesLogix web uses JavaScript to launch these lookups. You can see the invoke code of the JavaScript by putting your cursor over the lookup’s button. Once you know that syntax you can determine the server side code you would use to invoke the client side code. The code will typically look like this:

ScriptManager.RegisterClientScriptBlock(this, GetType(), "ShowLookup","$(document).ready(function() { setTimeout(function() { " + AssignTo.ClientID + "_luobj.show() }, 500) })",true);

The important thing here is to change the red part of the code to be the server side control ID of the lookup you wish to pop.

A heads up: The SalesLogix web Lookup Control is session cached

2009-11-20T13:03:40Z

I recently was having problems seeing changes I was making to a deployed ASP.Net SalesLogix web page. Specifically, the changes I was making to a Lookup control. What I discovered is that the changes to my page were not reflected in my lookup until after I logged out of the SalesLogix web client and logged back in. Simply refreshing my page in the browser had no affect. Apparently some information is being cached in session state. Just a heads up that if you are not seeing something work as you would expect in the SalesLogix web client, try logging out.

There are other things like changes to user security or information that I have also found are cached at log in so in general this is a good practice when testing out your pages.

Error attempting to sort a SalesLogix web grid control

2009-11-20T11:29:00Z

If you have ever added code similar to:

mygrid.Sort("CreateDate", SortDirection.Descending);

You may have seen an error similar to this:

System.Web.HttpException: The GridView 'mygrid' fired event Sorting which wasn't handled.

This is caused by attempting to call the sort method on a grid that does not have it's EnableSorting property set to True. Also, the column you are sorting should also have it's IsSortable and SortField properties defined.