11/21/2024 11:50:08 AM
slxdeveloper.com
Now Live!
|
|
| |
| Customizing SalesLogix with ASP.NET Applications |
|
| Description: |
In this article Stephen Redmond shares an extract from DevLogix 3rd Edition covering developing for SalesLogix using ASP.NET. Stephen touches on leveraging ASP.NET for both the SalesLogix Web and LAN clients.
|
| Category: |
ASP & ASP.NET Development
|
| Author: |
Stephen Redmond
|
| Submitted: |
10/7/2005
|
| |
|
| Stats: |
Article has been read 27965 times
|
Rating:
  - 4.6 out of 5 by 5 users |
|
|
|
fiogf49gjkf0d
In this article Stephen Redmond shares an extract from DevLogix 3rd Edition covering developing for SalesLogix using ASP.NET. Stephen touches on leveraging ASP.NET for both the SalesLogix Web and LAN clients.
One of the great things about SalesLogix 6.x is that you have a scalable OLE DB connection that can be used from external applications. This includes web applications.
There are times when the SalesLogix Web development environment becomes very unwieldy to develop add-on forms for the Web client. In those circumstances, I turn to ASP.NET.
When I write such applications, I will generally do the following:
- Store the SalesLogix Connection String in the Application settings in web.config.
- Place a button to call the application on the relevant SalesLogix web form - this is a simple piece of HTML and JavaScript.
- Such buttons should pass through the current user id, and the current entity id to the ASP/ASP.NET application.
e.g. In the con_info template, you may have code like this:
<input type="button" id="btnMyApp" value="Call My App" onclick="window.open('/Path/MyApplication.aspx?
ContactID=<#FIELD name=conid>&UserID=<#SYS name=theuserid>','MyApp','width=260,height=160')"></input>
This code calls the MyApplication.aspx application and passes through the current ContactID and UserID.
It is important to pass through these because you are connecting via a generic connection string (usually using the Admin login) so you need to know what User is making any changes, etc., and what record is being changed.
- If you want a "Main View" type arrangement, where your application fits in the web client as if it is part of the SalesLogix web, then you should place your code in the leftnav template and add a button to call your app with code such as:
MenuID.push("myapp2");
MenuAdd.push("/Path/MyApp2.aspx?UserID=<#SYS name=theuserid>");
MenuText.push("MyApp");
And don’t forget to add an Image reference in the initImgRefs function.
Other than those things, creating ASP/ASP.NET applications for SalesLogix is a breeze for ASP developers.
If I can call an aspx application from the web client and pass parameters, I can certainly do so from within the "Thick" client also.
I have a choice here. I can either call the application in a web browser using the WebOpen call, or, I can add more control by having a form with the Browser control on it and open the page in there.
A great advantage of this approach is that you can build one customization that works on either your Web or Network clients. This saves on the double-development issue that affects developing for both platforms.
Of course, this might be a problem for your remotes. They will not have access to the web server all the time so cannot run the ASPX application.
The ASP.NET Cassini Web Server Sample is a sample web server written using the Microsoft® .NET® Framework, and demonstrates hosting ASP.NET using the ASP.NET hosting APIs (System.Web.Hosting).
It is freely downloadable from http://www.asp.net/Projects/Cassini/Download/ and includes full source code.
This source code can be easily modified to run the server as a Windows Service and to run the automatically.
Why am I talking about it? Well, if you configure your remote SalesLogix users with a Cassini service running on port, say, 8800, and they have a local copy of the ASPX pages and code. Then you can manage your SalesLogix code to run a particular URL depending on whether the user is on the network or remote.
The joy of ASP.NET is that you can just drop in updated pages and code and they become available immediately so managing updates to the ASPX application should be quite straightforward.
ASP.NET is a powerful platform for developing great applications. The SalesLogix architecture allows you to develop ASPX application that interact successfully with your SalesLogix data. Using these techniques, you can design modern looking, attractive forms, that run on all your platforms.
Based on an extract from DevLogix 3rd Edition, Copyright © 2005, Stephen Redmond.
|
|
|
Stephen Redmond
(SalesLogix Business Partner)
Capricorn Ventis Ltd.
fiogf49gjkf0d Author of the excellent DevLogix - A Guide to SalesLogix Development (now in 5th edition).
View online profile for Stephen Redmond
|
|
|
|
Rate This Article
|
you must log-in to rate articles. [login here]
|
|
|
|
Please log in to rate article. |
|
|
|
Comments & Discussion
|
you must log-in to add comments. [login here]
|
|
|
- subject is missing.
- comment text is missing.
|
|
|
| Re: Customizing SalesLogix with ASP.NET Applications
Posted: 10/7/2005 3:36:33 PM | fiogf49gjkf0d Great stuff, Stephen. I look forward to the release of DevLogix 3rd edition.
-Ryan | |
|
| Re: Customizing SalesLogix with ASP.NET Applications
Posted: 10/12/2005 6:59:02 AM | fiogf49gjkf0d I don't work with the web client, but I do work with ASP.NET quite a bit. It seems risky to pass the UserID in the querystring and use a generic OleDb connection since the savvy user could edit the UserID in the resulting browser window's Address bar. Essentially it enables someone to impersonate any user even if they don't have the necessary security.
Also, some pop-up blockers will prevent the window.open command from firing, so this approach should be limited to a user base that has control over their browser settings. | |
|
| Re: Customizing SalesLogix with ASP.NET Applications
Posted: 10/12/2005 12:43:18 PM | fiogf49gjkf0d Very valid comments Rick - but I would put them in the "things to be aware of during implementation" rather than "reasons not to consider the technology".
The window.open issue is not such a biggie because it can easily circumvented - most user do have control over their popup blockers and for those that don't, it can be easily added into the system policies by administrators.
If you open your windows as dialogs, the user does not get to see the URL (or do things such as Ctrl-N) to hack it out. If you are calling the code from within SalesLogix, you can present it using a Browser control on a form and the user, again, does not see the URL.
There are lots of things such as these to consider in a real implementation - not least of which is ensuring that your code can't suffer from SQL injection attacks. However, this article is really meant to introduce the concept and is not meant at as a complete planning and implementation guide (now there is a book idea!)
Stephen
| |
|
| |
| |
|
|
|
|
Visit the slxdeveloper.com Community Forums!
Not finding the information you need here? Try the forums! Get help from others in the community, share your expertise, get what you need from the slxdeveloper.com community. Go to the forums...
|
|
|
|
|
|