The upgrade process for Sage SalesLogix v7.5 Service Pack 4 is different than previous service packs because SP4 includes a full install. It’s very similar to the process of installing the base v7.5.0 product—except with a lot more features in the end! They are so similar in fact, that if you are installing Sage SalesLogix in a new, on-premise environment, you can go directly to the SP4 installer (no v7.5.0 necessary). If upgrading from an existing v7.5.X* environment, on the other hand, the SP4 installer runs in the same way except that it first removes applications with prior version and then re-installs them.
During the installation (or re-installation) for each feature (Admin Tools & Servers, Client, Web Host, Web Reporting, and so on), the SP4 installation wizard inspects your system for necessary prerequisites and even finds the appropriate installer for you, which makes the process extremely seamless. The Applying Service Pack 4 for Sage Saleslogix Version 7.5 documentation is the ultimate resource for choosing the right upgrade workplan for your environment. Always defer to the documentation when performing an upgrade in a production environment.
Now that the disclaimer is out of the way, I can reveal the following [abbreviated] steps that we use in Training to upgrade our image from v7.5.0–>v7.5.4. (Upgrading from v7.5.3–>v7.5.4 is similar, but you can skip steps 1, 9, and 10 if you already did them for SP3.)
Delete the MergeConfiguration.xml file and the PotentialMatchConfiguration.xml file in Application Architect.
Run the Setup.exe, and install Administrative Tools and Servers. (Restart.)
Run the Setup.exe, and install the LAN or Remote Client.
Install the LAN bundle in the Administrator.
Run the Setup.exe, and install the Web Host on IIS.
Run the Setup.exe, and install the Web Reporting Server.
Restore the SP4 project backup, rebuild web platform, deploy core portals.
Run the Role Security utility.
Add users to the Standard User role in the Web Client.
Reconfigure Web Reporting in the Application Architect.
Here’s a video of me going through the steps for the RC1 version with a bit more explanation. We skipped many recommended tasks from the documentation that you should perform on a production environment, but did I miss anything?**
Although I won’t review all of the enhancements from SP4—the Applying Service Pack 4 for Sage Saleslogix Version 7.5 documentation is the best resource for a comprehensive list—here are a few that we’re especially partial to in Training:
Duplicate Checker (for Web Administrators):
This tool is available under the Tools menu when logged on as “admin.” You can also grant a standard user access to this tool by adding the user to the Data Quality Manager role. It allows you to search within any group for Account, Contact, or Lead tables and look for duplicate records in the database. This feature locates matches and scores them based on match probability, and then it allows you to resolve any duplicates by merging records. Service Pack 3 introduced the ability to merge records in the Web Client List view (right-click > merge), but you still had to spot-check for the duplicate records manually. The SP4 enhancement automates the process AND includes the Lead table.
Notes/History tab (for Web End Users): This enhancement brings the familiar Notes/History tab that we love from the LAN Client into the Web! It combines both history items and notes. You can filter the grid based on a variety of criteria, and you can even send any selected items to e-mail or to Word.
Editable Sales Order Data Grid: Now you can more easily update pricing and discount for a sales order. (Not to mention use a revamped Accounting Integration process! More to come on this in later posts.)
SData Enhancements (for Web Developers):
In addition to excluding individual entity properties from the SData payload, you can also prohibit Create/Update/Delete SData operations on an entity. Also, more entities are exposed to SData.
Enable Field-Level Security for New Entities (for Web Developers):
Many more!
*If upgrading from an existing environment earlier than v7.5.0, you must first upgrade to v7.5.0 before running the SP4 installer.
**If you learned one thing from this post, let it be that you should read the service pack documentation!
Updated: Added the task to delete the PotentialMatchConfiguration.xml file to step 1.
I have been working a lot with the New Sage SalesLogix Mobile product. We have a new master’s series class, many developer subscription videos, a production release setup which our internal PSG team developed, and now a v1.1 class. This was a lot of work, but man is it fun to work on such a sleek, great looking, and fast product. We have talked about the background of mobile before but we now really have two main versions: 1.0 and 1.1.
Versions
Version 1.0 of the New Sage SalesLogix Mobile Web works with 7.5.3, but really needs HF3 to be fully functional.
Version 1.1 of the New Sage SalesLogix Mobile Web works with 7.5.4. Absolutely needs 7.5.4 since some additional SData endpoints were added to support v. 1.1.
Everything I did in version 1.0 worked in version 1.1. No problems. The one catch is I also tried this on a 7.5.3 installation and got an error right after login. I just could not figure it out. I saw the end point and emailed a developer to see what was up. Turns out the above requirements stand. I needed 7.5.4 to run the newest downloads from github.
Here are the things I know about the New Sage SalesLogix Mobile product: It’s new, it’s mobile, and it’s awesome!
Installation
Installing the out-of-the-box product is a breeze. Simply add the mobile bundle in the Application Architect, configure a new portal, and deploy to your production Web server. Your sales staff can access account information on their mobile devices faster than I can power on my laptop.
Customization
Customizing the mobile client is simple, but it does require you to do more configuration for setting up your development environment than what is required for out-of-the-box production. However, once you understand why you need to set up a series of folders—to take advantage of plugin architecture—the process becomes easily manageable. For example, imagine you want to add a new Edit, Detail, and List view for a custom entity (i.e. clientproject). After enabling the entity for SData, here’s what your development folder structure might look like (not all folders are listed):
So for any customization, we somewhat replicate the argos-saleslogix folder/file structure in order to merge our new changes into the base site. Then you might ask, “Why do we create a new folder inside products? Can we modify inside of argos-saleslogix instead?” Well, the answer is, you can modify the argos-saleslogix contents and ignore the plugin architecture. However, any time you deploy from Application Architect, you would overwrite your changes. Also, future upgrades to the product would break your customizations. Still unsure? Check out a video showing an easy example with an explanation of why NOT to do that easy example. :)
Another question you might ask is, “Why go to the trouble of setting up your development environment by copying these folders—if the production environment was so easy, can’t we just copy the production deployment and push those files out through the Application Architect?” Although that’s a nice idea, the beauty of using JavaScript is that it can be minified for faster load times for production. Our browsers read code like that very well, but it’s not readable for an average developer trying to romance the code.
For more information, register for the New Sage SalesLogix Mobile Master’s Series course. We’ll create a new entity (clientproject) and show you how to add a new List, Detail, and Edit view—as well as associate projects to accounts and associate tickets to projects.
Sage Data (SData) provides a simple standard protocol for reading data from and writing data to Sage Business Applications. It enables desktop, server, and Web-based applications to communicate with each other, and also with third-party applications and the world wide web. To find out more about SData™, visit http://sdata.sage.com.
Let’s configure SData™ for Sage SalesLogix!
Before you can use SData™ in your Sage SalesLogix customization projects, you need to ensure your environment is configured appropriately. Here are a few steps you should take:
1. Map the Sage SalesLogix admin user to your Windows WebDLL user*:
Learn more about the WebDLL user in this excerpt from the Sage SalesLogix Implementation Guide.
Log on to the SalesLogix Administrator as admin.
From the list of users, double-click the Administrator user.
Select the Use Windows Authentication check box, and then map your WebDLL user on your server inside the Windows ID box. If prompted to import information from Active Directory, say no. (Although it shouldn’t matter for the WebDLL user.)
Click OK.
2. Deploy the SData portal:
Log on to the SalesLogix Application Architect as admin.
From the Deployment Explorer, expand the Deployments node, and then double-click Core Portals.
From the list of Deployment Targets, right-click the sdata node, and then click Deploy Portal.
Close Application Architect.
3. Enable basic authentication:
This step is not necessary anymore (since v7.5.3 HF3) because basic authentication is enabled by default. As long as SData is accessed via https, basic authentication provides you with the security you need. Read more about SData and basic authentication/digest authentication from a previous post.
4. Disable Windows Authentication in IIS:
Within IIS, right-click the sdata node, and then click Properties. The SData Properties window appears.
Click the Directory Security tab.
Next to the Authentication and access control option, click Edit. The Authentication Methods window appears.
Clear the Integrated Windows authentication check box, and then click OK.
Click OK to close the Properties window.
5. Configure handler mapping:
Within IIS, right-click the sdata node, and then click Properties. The SData Properties window appears.
From the Virtual Directory tab, click the Configuration button.
From the list of application extensions, click the ascx extension, and then click Edit.
Right-click in the Executable box, and then click Copy.
Click Cancel to return to the Application Configuration window.
Click Insert.
Right-click in the Executable box, and then click Paste.
Clear the Verify that file exists check box.
Click OK, and then click OK again.
Close and restart IIS.
Now let’s check to see if it’s working!
Open Internet Explorer. (You can use any browser, but the feed is easier to read in IE.)
Browse to http://[yourservername]:3333/sdata/$system/adapters.
A log on prompt should appear. Make sure the dialog says “The server [yourservername] at SalesLogix Client requires a username and password.” If it is blank or says something else, something isn’t right.
Enter any SalesLogix username and password, and then click OK.
You should now see your SalesLogix SData feed. Click on some of the links to see what kind of data is returned. For example, http://[yourservername]:3333/sdata/slx/dynamic/-accounts. You should see a list of all your SalesLogix accounts.
Uh oh. It’s not working
If your SData feed did not appear, recheck your steps. The error message that you receive from your browser can tell you a lot. Check out this flow chart to see if your error matches any of these.
Another option is to visit the Sage SalesLogix community. Chances are, someone has already posted a question that relates to the same issue you might be having. If not, you can post your own and get answers from other Sage SalesLogix experts.
Sometimes when we learn of a new technology we tend to want to use that technology for everything. In many cases this is a good thing, in other cases you end up pounding a square peg into a round hole. Perhaps the round hole hole is large enough to accommodate the square peg, but it is still not the best fit.
You probably have several projects that SData can fit into. Perhaps integrating with a third party application or data loads from remote employees. Stuff like that. It makes sense to use SData when the systems are different enough — Java interfacing with ASP.NET — or far enough apart — the application is not able to communicate with the database via other means. It is ok to be excited about the newest method to retrieve data from SalesLogix. Once you understand SData and have learned to use the client libraries then the world is yours.
In SalesLogix training we usually get questions when something goes wrong not when new code is being written and everything is going fine. Recently we had the chance to work on a new project that was going just fine, but we were asked to work as developers on the project. The project was a web based project written in ASP.NET (C#) and would in all likelihood sit on the same web server as the slxclient portal. A request would come into this website against one of about 7 pages. It would contain an xml feed. The page would take the xml feed and fill it in with data from SalesLogix and return the filled in xml as the response.
Using SData you would have had the initial request to my page, the http request from my page to SData, and then SData‘s request to the database using the entity model. Since the new website sat on the same web server as SData, you can be sure that there is a port open (probably 1706) to the SalesLogix server, and that we could use ADO.NET to eliminate that last request from my webpage to SData.
The final result
The final result was we ended up with a website returning xml data which it retrieved using ADO.NET directly from the database. Nothing fancy — the same thing we have been doing for years. We were not using SData at all though. No client libraries were used just plain old ADO.NET and ASP.NET.
Other considerations
By not using SData we were also not using the entity model. This means any onbeforeupdate type events we had written will not be used. The argument can be made that these are important and if that is the case SData or working directly with the entity model is a good option. The learning curve of working directly with the entity model outside of SalesLogix might outweigh the gains initially, but the performance and code reuse benefits will certainly be there.
Inside our Developers, Administrator, and End User Subscriptions we give you the ability to request a topic or “How Do I.” We get a lot of good requests and have recorded many of these. We cannot get to them all, but we evaluate each one and categorize and prioritize them as a group.
Sometimes we get a request that just doesn’t fit. They could be a video, could be a blog entry or just an email will suffice. This next one fits into a mixture, so here we go. The question was that the video we have on merge and diff does not:
appear to elaborate on the parameters that we are supposed to pass to DiffMerge. We would like to use that bundled tool to help us work through the customizations our vendor partner implemented
This interested me a lot since I like KDiff3 and I know different developers have their preference or have already purchased a solution. So how can I show the options in one area? Of course I went to Google <-click the link and you can see me Google.
James does a great job of showing the most common tools and their parameters. Application Architect allows for a %File1% and a %File2% which can replace James’ %1 and %2. I wont steal the charts from his site, but this is what I enter for diffmerge:
I regularly use FireBug in Firefox my for my JavaScript debugging. Back in the mozilla days I would just enter javascript: in the address bar and get the nice dialogue that shows to tell me the location of the error. We can all agree we have come a long way. Now that Firebug is also in Chrome we have another tool. I admit I do not bother with JS debugging in IE much, but I have pressed F12 a few times in the app to get up the dev tools.
So to put it short I could not do as good of a job as the guys over at alistapart.com. Check out what they have to say about debugging in JS “after the jump”:
“When used effectively, JavaScript debuggers help find and squash errors in your JavaScript code. To become an advanced JavaScript debugger, you’ll need to know about the debuggers available to you, the typical JavaScript debugging workflow, and code requirements for effective debugging. In this article, we’ll discuss advanced debugging techniques for diagnosing and treating bugs using a sample web application.”
We’re two Master’s Series deep! This week we finished our second series topic, Client-Side Coding Techniques, which followed our inaugural offering, SData v1.0 in December.
Did you miss a session? Fear not! You can attend a make-up session for Client-Side Coding Techniques or the revised SData 1.1 course in March. Visit http://www.sageu.com/saleslogix/masters/ for details and registration.
Sorry, I’m new here. What’s a M-M-M-Master’s Series?
Check out the Master’s Series Mashup for the two-minute skinny:
There are plenty of lists showing what tools every .NET developer should have and even a list from Hanselman himself, but what about a SalesLogix developer? I figured I would share some of the tools I use on a regular basis here and let you add yours in the comments:
Notepad ++ – just a better editor. Syntax highlighting and all that. An easy replacement for notepad
FireFox and Firebug Firefox is safer and all that but firebug is a tool that let’s you code client side 1000X faster. (available for chrome too) Press F12 to see it in FF or IE
ScreenToaster – I use screen toaster to record my screen for demos, to help someone and to record bugs. I get others to use it to effectively share with me too. It is a browser based screen recorder.
So that is pretty much what we all knew already. Perhaps there is one or two tools on the list you do not already have/use. What about resources? Can we list those as well?
If you aren’t watching these blogs or websites – do! The authors take a lot of time to add content and it is for you. Just add it to your favorite reader. I use outlook believe it or not. It is always open and always there. Google Reader is a close second.
It looks like the development team has taken the steps necessary to officially release the SData Client Libraries to Partners. There are a couple demo apps included and one is a rewrite of the app we use in our SData Master’s Series class! Well they took that app and updated the Client Libraries and together reduced the code we need to write by more than 25%.
What changed?
Really the payload was put into a dictionary. A simple explanation of a dictionary in C# is a multidimensional array. Most of the time you have a key and a value. So in our case this becomes the field name (or entity property name if you must) and the value. There are a few other changes as well, but this is the biggest.
What does this do for me, the developer?
This means that in order to get a value from an SData feed you need to get the payload and then request the field by name. Seem familiar? It is sort of like getting a recordset and asking for a field. In most cases we treat a recordset in ADO like a multidimensional array. This should be an easy transition for most of us.
In my opinion this makes the Client Libraries much more useful. As the (genius) develop put it: “the user no longer needs to know any xml.” – WOW. No more of the nil=true mistakes or missing a namespace.
Code
Some simple code changes (as outlined by the developer in the rewritten app:
XPathNavigator tempContactPayload = tempContactEntry.GetSDataPayload();//create the XML document for the new
var doc =new XmlDocument();
doc.LoadXml(tempContactPayload.OuterXml);//setup the navigator and namespace alias
XPathNavigator navContact = doc.DocumentElement.CreateNavigator();
XmlNamespaceManager managerTemplate =new XmlNamespaceManager(tempContactPayload.NameTable);
managerTemplate.AddNamespace("slx", "http://schemas.sage.com/dynamic/2007");
managerTemplate.AddNamespace("sdata", "http://schemas.sage.com/sdata/2008/1");
managerTemplate.AddNamespace("xsi", "http://www.w3.org/2001/XMLSchema-instance");
navContact.MoveToFirst();
navContact.SelectSingleNode("//slx:FirstName", managerTemplate).SetValue(txtFirstName.Text.ToString());//delete xsi:null from payload...
var nil = navContact.SelectSingleNode("//slx:FirstName", managerTemplate).SelectSingleNode("@xsi:nil", managerTemplate);if(nil !=null) nil.DeleteSelf();//update the payload
tempContactEntry.SetSDataPayload(navContact);
After:
var tempContactPayload = tempContactEntry.GetSDataPayload();
tempContactPayload.Values["FirstName"]= txtFirstName.Text;
So you can see this is much cleaner, easier and thus faster to develop against.
How can you tell which version you are using?
Well if you have downloaded anything from training prior to the date of this post you have the “old” version. This will usually mean the .Values from the above code will fail. So you can easily tell from that OR the new dll should have a version of 1.1 .
We will be offering an updated version of the SData class using the new and improved code. If you have attended the previous SData class you know there is no additional cost for you to attend and we plan on providing a simplified “what’s changed” version in that class as well.
