Before students attend the Implementing or Administering Sage SalesLogix course, we ask them to complete the Introduction to Sage SalesLogix course. This Anytime Learning course contains three components:

1. Windows Administrator Fundamentals
• Client/Server Architecture
• Services
• IIS and Web Hosting
• Relational Databases
• Windows Domain, User Permissions, and Shared Folders
2. Sage SalesLogix Fundamentals
• Introduction to SalesLogix
• Accounts and Contacts
• Leads
• Opportunities
• Dashboards
• Tickets
• Lookups and Groups
3. Pre-Assessment

Why do we offer this course? One reason is that we no longer teach Sage SalesLogix fundamentals in the Admin/Imp courses, so this course is often the first chance that a new administrator sees the product that they are about to be responsible for administering! The other reason is to get students up to speed on basic Windows administrative functions that are required of someone in this capacity. The pre-assessment includes 20 multiple-choice questions, and it simply helps assess how well your skills meet class expectations. It’s no big deal if you don’t get a perfect score, but it could save you a week’s worth of frustration in training if you determine early that you may not be the person at your company to assume this role.

If you’re interested, take some time to check it out—there is no cost for registration!

The Upgrade Process

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.)

1. Delete the MergeConfiguration.xml file and the PotentialMatchConfiguration.xml file in Application Architect.
2. Run the Setup.exe, and install Administrative Tools and Servers. (Restart.)
3. Run the Setup.exe, and install the LAN or Remote Client.
4. Install the LAN bundle in the Administrator.
5. Run the Setup.exe, and install the Web Host on IIS.
6. Run the Setup.exe, and install the Web Reporting Server.
7. Restore the SP4 project backup, rebuild web platform, deploy core portals.
8. Run the Role Security utility.
9. Add users to the Standard User role in the Web Client.
10. 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?**

For more videos like this one, subscribe to the Sage SalesLogix Administrator’s Subscription or contact training.crm@sage.com.

The Enhancements

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!

The Disconnected Web Client (also known as Offline Web Client*) allows any Sage SalesLogix Web user to access Sage SalesLogix data even when there is not a regularly-available Internet connection. Instead of accessing the main web site through a browser, a user can access a local web site (also through a browser), but one that is tied to the user’s remote database as opposed to the host. This database and web portal reside on the user’s laptop. They are essentially a replica of what is typically hosted on the main Web or Database Server in the Cloud—but a replica that is only accessed by the specific user on his or her hard drive.

When the user gets access to an Internet connection again, data in the remote database gets synced back up to the host, and data that was changed on the host while the user was disconnected gets synced back down to the remote.

For either on-premise or Cloud, in order to use the Disconnected Web Client, the user must install the Sync Client (to transfer data back and forth) and Personal Web Server (to host the local web site and related files). The user must also have a version of SQL Server installed and attach the remote database. As the administrator, installing these applications for your users isn’t the hard part—it’s finding a time when you and the remote user are in the same physical location! So to help get a user up-and-running more quickly, the process just got easier! Specific to the Cloud environment (for now), users can download required files directly from inside of the Sage SalesLogix Web site itself. The installation process even takes care of all the machine pre-requisites for the user.

Cloud Administrator’s Steps

The following steps assume the sync server is installed and a sync transfer profile has been created.

1. In the Administrator application, create a remote user (or change an existing network user to a remote user type).
2. Modify the Sync tab in the remote user’s profile: Select the Synchronize Changes check box, assign a Sync Transfer Profile, and select the accounts to sync (All or Specific/Subscription).



3. Create the remote user database. The location for the database must be in E:\Filestore\Downloads.



4. In the Application Architect, deploy the SlxClient and SlxIntellisync portals to to the selected user.



5. Cycle the Sync Server.

Check out this Cloud Administrator video to watch these steps performed.

Cloud End User’s Steps

1. Open a browser, and log on to the host Sage SalesLogix Web Client site.
2. From the Support Nav Bar, click Client Downloads.
3. Click the link to Download and Install Sage SalesLogix.



4. Choose to run or save the SlxDisconnectedWebClientSetup file. It may take a few minutes to download.
5. When the installation wizard starts, note the list of prerequisites, if any (specific to your machine). Follow the onscreen prompts to install each prerequisite. If any of them fail, continue with the installation, but when it is complete, go back and start it again to retry.



6. When all prerequisites are installed, the Sage SalesLogix Disconnected Web Client wizard starts. Click through the onscreen prompts to install. This process installs the Sync Client and SalesLogix Web Server.



7. Open a browser, and log on to the host Sage SalesLogix Web Client site again. From the Client Downloads page, click the link to Download and attach your SalesLogix Database.



8. Save the downloaded database to the desktop (or other location on your hard drive).
9. Double-click the file to open the Remote Database Setup dialog and attach the database.



10. From the Start menu, point to All Programs, point to Sage SalesLogix, and then click Synchronization Client.
11. Log on to the SLXRemote database connection using your SalesLogix username and password.
12. Click Sync Now, and wait for the cycle to complete
13. From the Start menu, point to All Programs, point to Sage SalesLogix, and then click SalesLogix Web Server. (Or right-click the Web Server icon in your System Tray, and click Open Site.) Tip – if the Open Site option is grayed out, click the Properties option, and then click the Start button in the Sage SalesLogix Personal Web Server window.


Start the DWC Web Site and log on.

14. On the SalesLogix Log On page, note the address bar shows “localhost” in the URL. This is your OWN web site, disconnected from the host. Log on using your username and password.

That’s it! You’re now ready to work in an offline mode whenever you do not have an Internet connection. Periodically, whenever you obtain an Internet connection again, run a sync (using the Sync Client) to push your changes back up to the host database and to pull changes to your database. You can even set your sync client to sync on a schedule. After you sync, you can continue to use the Disconnected Web Client (using the “localhost” web address) or go back to the host SalesLogix web address—the tool is flexible enough to accommodate your accessibility.

Check out this Cloud End User video to watch these steps performed.

**********************************
*The Disconnected Web Client will be known as Offline Web Client in future releases.

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.

1. Log on to the SalesLogix Administrator as admin.
2. From the list of users, double-click the Administrator user.
3. 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.)
   
   
   
4. Click OK.

2. Deploy the SData portal:

1. Log on to the SalesLogix Application Architect as admin.
2. From the Deployment Explorer, expand the Deployments node, and then double-click Core Portals.
3. From the list of Deployment Targets, right-click the sdata node, and then click Deploy Portal.
4. 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:

1. Within IIS, right-click the sdata node, and then click Properties. The SData Properties window appears.
2. Click the Directory Security tab.
3. Next to the Authentication and access control option, click Edit. The Authentication Methods window appears.
4. Clear the Integrated Windows authentication check box, and then click OK.
5. Click OK to close the Properties window.

5. Configure handler mapping:

1. Within IIS, right-click the sdata node, and then click Properties. The SData Properties window appears.
2. From the Virtual Directory tab, click the Configuration button.
3. From the list of application extensions, click the ascx extension, and then click Edit.
4. Right-click in the Executable box, and then click Copy.
5. Click Cancel to return to the Application Configuration window.
6. Click Insert.
7. Right-click in the Executable box, and then click Paste.
8. Clear the Verify that file exists check box.
9. Click OK, and then click OK again.
10. Close and restart IIS.

Now let’s check to see if it’s working!

1. Open Internet Explorer. (You can use any browser, but the feed is easier to read in IE.)
2. 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.

3. Enter any SalesLogix username and password, and then click OK.
   
   
4. 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.

Also check out the Sage SalesLogix Customer Resource Center for links and other contact information for the Sage SalesLogix Support team.

*As of 7.5.3 HF3, when using Basic Authentication, you no longer need to configure the WebDLL user with ADMIN User.

The Web Administration tool set is scheduled for v7.5.3 on-premise release this summer. Great! But…what exactly is it? When we refer to “administration tools” for Sage SalesLogix LAN, it usually means one of two things:

Features accessible from within the SalesLogix Client interface; a user must have appropriate permissions (function security) to see these features: (Click image to enlarge)
Features only accessible from within the LAN Administrator interface; a user must be logged on as “admin” to see these features: (Click image to enlarge)

Now, when we talk about “administration tools” for Sage SalesLogix Web, we actually combine both of these definitions! First, users with appropriate admin permissions can access the Web Administrator from the same point of entry that they use to access other end user features in the SalesLogix Web Client. Second, in addition to providing common list management functions (competitors, lead sources, products, pick lists, literature items, packages), the Web Administration tool set also includes functions that were previously only available to the designated admin user (users, departments, teams, roles*).

*New functions available only for Sage SalesLogix Web. Roles allow/restrict user access to certain Web Client or Web Administration features using secured actions—similar to “Function Security” for LAN Client users.

Everyone here is looking forward to this release making for very cool summer in Scottsdale!

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.

SData is a very nice square peg

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.

Anyway I was left here:

http://blogs.msdn.com/jmanning/articles/535573.aspx.

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 hope that helps to clear that up.

As a SalesLogix administrator, you can configure many default settings in the SalesLogix Client so they match your company’s processes or look-and-feel. Templates used for letters and mail merge are no different; in fact, you have probably very easily figured out how to create new, private templates with your company’s own logo. When it comes to modifying those default public templates, however, you may have felt like that area is a Secret Template Guru Club to which someone forget to invite you. This article provides you with some easy steps to isolate those plugins in the LAN Architect and make global changes. We invite you to not only enter the clubhouse, but to also become a full-blown member!

About Templates

Templates are predefined documents that contain reusable text combined with merge fields to automatically personalize a document for a selected contact or lead. Templates save you from having to recreate the same letter each time you want to send correspondence to your customers. SalesLogix contains base templates for letters, e-mail messages, and fax cover sheets. As the administrator, you can create additional templates for users, or they can create their own.

To view the default templates:

• LAN Client: From the main menu, click Write > Templates.
• Web Client: Enable ActiveMail upon log on. Then from the main menu, click Write > Manage Templates.

Private vs. Public Templates

There are two types of templates available: Public and Private.

• Public: These templates are what we refer to as the out-of-the-box or default templates. These templates are available for everyone to use and copy as private templates. Only the administrator can change or delete these templates…only if you know where to look!
• Private: These templates are created by a SalesLogix user. Any templates you create when logged on to the SalesLogix Client—as the administrator or a SalesLogix user—will exist as private templates. Additionally, any public templates you copy will also be saved as private. Only the user who created the template will have access to the template. If you want to share the private template with another user, you can do so, but you should make a copy of the template first. Either way, whatever you do to a template within the Client application will always remain as a private template type.

Modify a Public Template

Ok, enough of the teaser already—tell me how to modify a public template!

1. Log on to the SalesLogix Architect as admin.
2. Click Cancel on the Open Project window.
3. From the Manage menu, click Plugins.
4. From the Manage Plugins window, change the Type option to show Templates, Mail Merge.
   
5. Right-click the template you want to edit, and then click Open Plugin.
6. Modify the template as needed&madash;add your company logo or change the font theme— and then click Save and Close.
   The template will automatically be changed for all SalesLogix users at this point. Most plugin customizations require you to release them before making them available to users, but there is no need to re-release for these default templates.

Ta-da! You now get access to the Secret Template Guru Club’s members-only password: Templatopia!

No. It isn’t.

By default SData will use Digest Authentication. We talked about this a bit already here.

Enable it

In the web.config you can change the following section:

		<httpModules>
			<clear/>
			<add name="Session" type="System.Web.SessionState.SessionStateModule"/>
			<add name="AppManager" type="Sage.Platform.Application.UI.Web.AppManagerModule, Sage.Platform.Application.UI.Web"/>
			<add name="BasicAuthenticationModule" type="Sage.SalesLogix.Web.SLXWebBasicAuthenticationModule, Sage.SalesLogix.Web"/>

This allows the BasicAuthenticationModule to do it’s thing.

Meeting many of you at Insights and Summit we in training know that you wear many hats. Some of you own the business, install the application for your clients, customize the product and support it for 10+ years and more! Some of the people I meet work for a customer and they are the SalesLogix “guy” or “gal” in the company. We have a student this week that is taking a developer course and has no development experience, but is going to be the main “gal” at the company in a few weeks.

Let’s talk perspective

The many hats you wear mean you do different jobs, but in my experience with all of you I see two main types of people: Administrators and Developers. Why the disctinction? Perspective.

An Administrator likes to have things in order, memorize details and steps, reads the manual and expects things to work (or fail) as expected. Resolutions are documented, reasons are sounds and reproduce-able, and overall it is a very structured world.

A Developer on the other hand expects to figure it out each and every time an error occurs. Never is something going as planned nor will the same circumstances repeat themselves – why bother to document it.

Why does this matter?

Administrators doing development tend to have a hard time adjusting to this fluid development environment. Especially when it comes to .NET and the various opportunities we have to debug an application in AA, outside AA in event viewer etc. It is not cut and dry, each scenario is different on just about each machine. Developers love to figure it out – even if it takes all day.

Developers have a similar problem with administration tasks. There are rules you follow when administering a SalesLogix installation. Just like good comments in code you follow the Administration rules so that the next SalesLogix Administrator can make the assumptions that they always make — they have the installation memorized if your read the manual! Administrators do not have all day to figure it out! Production is down and it needs to be back up now!

Can’t we all just get a long

We can. In some cases we are fighting with ourselves or we are doing something (like not documenting) that will come back to haunt us in the future. Best practices are like gold to an Administrator and boring drivel to a programmer. I know you have some good stories to tell, so please do – in the comments.