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.