I recently saw an issue where groups would not load in SalesLogix 7.5.1 web. Not a single group would load. You’d see the spinning circle as if it were attempting to load the group. However, that would disappear and then…nothing. No group data would appear. Not just the data, but not even the group definition, so you wouldn’t even see any column headers. With a little troubleshooting the problem was easy to track down, and the solution turned out to be a simple one.
The problem was that no groups would load. None. Not for any user at all. It would look as if it were loading, but then you’d end up with nothing at all. No data, not even the column headers would show up as seen in the screenshot below:
Pretty frustrating since I had some difficulty thinking where I should start looking. Let’s go through the process I followed to find the issue and solution before we just right to the fix.
Troubleshooting to Discover the Cause
It is sometimes difficult to know where to start with an issue like this. One thing I did know is that the groups are loaded asynchronously, from the client (not loaded on the server and returned to the page). So, it made sense that I would see a request being made from my browser to get the group data. There is a great tool to see that sort of thing called Fiddler. Fiddler is a tool that will let you monitor and watch all HTTP traffic from your computer to the server. Looking at the traffic we should see this request and hopefully it will tell us something useful as to why the data is not returning.
Looking at the traffic from my computer to the server hosting SalesLogix there is one item that stands out. A request is returning an HTTP 500 error (which indicates an error occurred on the server executing the request). The URL being accessed is the following:
Also, worth noting is that the request is returning the typical ASP.NET error. Ah. That will help. If the request is throwing an unhandled error it should be logged in the event logs on the server.
Looking in the event logs we can find the following error logged:
Event Type: Error
Event Source: Sage.SData.Service
Event Category: None
Event ID: 0
Time: 4:45:31 PM
Exception caught during the processing of a message
Uri: http://saleslogix.customerfx.com/client/slxdata.ashx/slx/groups?family=TICKET&name=Ryans Tickets&format=json&meta=true&_dc=1251755197076&start=0&limit=150
Original Message: Thread was being aborted.
Stack Trace: at Sage.SalesLogix.Client.GroupBuilder.SLXSchemaInfo.RebuildXMLSchema(String constring, Boolean forceRebuild)
at Sage.SalesLogix.Client.GroupBuilder.GroupInfo.GetColumnsForTable(String TableName)
at Sage.SalesLogix.Client.GroupBuilder.GroupInfo.UseUCField(String sortOn)
at Sage.SalesLogix.Client.GroupBuilder.GroupsRequest.GetGroup(IRequest request)
at Invoke58748ac5b47c438e91099062b3de65cf.Invoke(Object , IRequest )
at Sage.Integration.Messaging.RequestTargetRegistration.RequestTargetInvoker.Invoke(IRequest request)
at Sage.Integration.Messaging.Request.Process(RequestTargetInvoker invoker)
at Sage.Integration.Messaging.MessagingService.Process(IRequest request)
Now we are getting somewhere. Looking at the stack trace we can see that the place this error is coming from is in the SLXSchemaInfo.RebuildXMLSchema method in the Sage.SalesLogix.Client.GroupBuilder.dll. Let’s open up Reflector and take a look at what is going on there.
We know the error is happening when this method is called (last method shown in the stack trace). Going through it we see that the first item called is “isRebuildFlagged”. The code in that method checks the results of the following query:
select datacode from plugin where pluginid=’XMLSCHEMA’
If the value returned by that query equals “REBUILD_SCHEMA” then it flags to the code to proceed and then “loadDbschema” is called. In this method the XML Schema is recreated and saved to the database. Checking this query in the SalesLogix database I could see that the value returned was “REBUILD_SCHEMA”. So, that is what is causing my problem, when the schema is being rebuilt.
Looking again at the event logs on the server that there was also another error logged immediately following the one I mentioned earlier. The error text logged was:
System.Web.HttpException: Request timed out.
The real issue here then, is that the call to rebuild the schema is timing out. It is taking longer to call the method to rebuild the schema than the default timeout setting on the server (the default ASP.NET execution timeout is 90 seconds).
Now that we know exactly what is causing the issue we can come up with a few reasonable solutions to fix it. Note, you do not have to do all of these, any single one of these solutions would work.
- Increase the timeout on the server. To increase this you can open the web.config and look for the executionTimeout attribute in the httpRuntime node. This value will be set to 90 if it hasn’t been changed before. Increase this number to a value large enough (in seconds) to allow the operation to complete. This will allow this to execute again in the future if needed, but use extreme caution when increasing the value to something too large as you’ll be opening yourself up to potential attacks.
- Open the LAN client and do something that will cause the XML schema to be rebuilt. One way to do this is to attempt to create a merge form. This will rebuild the schema if needed. This is a one time fix. If the schema changes and this flag is set again then this will need to be done again.
- Simply clear the “REBUILD_SCHEMA” flag from the datacode field in the database and just set it to NULL. The schema won’t be rebuilt, but it will stop attempting to rebuild it and the groups will load.
Well, there you have it. Of course, I could have just told you the problem and provide the fix. But that isn’t really what this post is about (well it is, but there is more). This post was really more of an exercise in troubleshooting. That’s the most difficult part of working with SalesLogix Web some times. Just knowing where to look and what to look for when an issue creeps in.