5/22/2024 4:33:07 PM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss the use of .NET Extensions in SalesLogix version 7 and higher. View the code of conduct for posting guidelines.
|
|
|
|
why not to use a .Net assembly in SalesLogic ??
Posted: 10 Jul 07 4:05 PM
|
What do you think of this comment:
SalesLogix has supported .Net assemblies for a couple of versions. They have to be built outside of SalesLogix in Visual Studio and assembled. Then they can be added into SalesLogix as a plug-in.
There are some good and bad points to this. The good is that it uses .Net and Visual Studio. The bad is that the source code is not in SalesLogix (this is bad for the client, not for us), and all of the connections to populate and update fields have to be programmed. |
|
|
|
Re: why not to use a .Net assembly in SalesLogic ??
Posted: 10 Jul 07 4:23 PM
|
| SLX has supported .NET assemblies, known as .NET Extensions since v7.0. You can write .NET code for any version of SLX, although you need to distribute the assembly yourself and manage the loading of the objects from it. The fact is that there is a right time and a wrong time to use .NET Extensions in SLX. Using this feature just for the sake of using the feature makes little sense - there can be extra steps needed to implement something as a .NET extension. A simple bound form is much simpler to implement as a SLX actve form than as a .NET Extension and there is no benefit to implement it as a .NET Extension anyway. However, there are some tasks that will be much easier when built using .NET vs standard SLX scripting. |
|
|
|
Re: why not to use a .Net assembly in SalesLogic ??
Posted: 10 Jul 07 7:47 PM
|
Hi Ryan - it would be great to hear a few examples of cases where you have found it easier to use .NET than standard SLX tools.
I'll start off - I would use a .NET app where any sort of multi-threading is required (eg a screen which fires off something that executes in the background, while allowing user input to continue). While this isn't 'easy', it just isn't possible at all in standard SLX scripting. |
|
|
|
Re: why not to use a .Net assembly in SalesLogic ??
Posted: 11 Jul 07 9:36 AM
|
| Well, we have extensive web site work hooking into the database, and we need to encrypt credit cards. I added the .Net DLL to SalesLogix so that both the web access layer and the forms in SalesLogix can use the same encryption and decryption functions. |
|
|
|
Re: why not to use a .Net assembly in SalesLogic ??
Posted: 12 Jul 07 6:38 AM
|
Originally posted by Jeff Weight
Well, we have extensive web site work hooking into the database, and we need to encrypt credit cards. I added the .Net DLL to SalesLogix so that both the web access layer and the forms in SalesLogix can use the same encryption and decryption functions. |
|
I'll make sure tio never purchase anything w/a CC from your site!...
Having said that.. in this day and age, you should be using a "commercial merchant account" and secure 3rd party CC processing. You should never save CC's in your db (too many identity theft things going on.. ) you could be in violation of agreements w/CC companies by saving CC numbers. You CAN save the auth code you get back (via 3rd party services) as an way of tracing purchases.
IF you want to know about companies that can assist or advise you in building a proper and secure CC processing web setup, contact me directlyt and I'll give you a name... and NO we don't do and won't do this type of work.. the libility is WAY to risky!
--
rjl |
|
|
|
Re: why not to use a .Net assembly in SalesLogic ??
Posted: 12 Jul 07 11:25 AM
|
Bob, your post reminded me of earlier posts by RJ Samp on the Sage BP Newsgroup.
And thanks for your offer, but our BP is doing enough to assist us with credit cards processing. Auth codes are nice if we actually didn't have multiple payments to run on payment plans set up for our customers - we have the sales rep get the auth code for the first payment though.
I should thank you, though, for spurring me to take a look at the Data Security Standard checklist sent to us by one of the credit card companies with which we work. We were in violation of just a few of the "just in case" checklist items, so we'll review those. |
|
|
|
Re: why not to use a .Net assembly in SalesLogic ??
Posted: 12 Jul 07 12:37 PM
|
Originally posted by Jeff Weight
Well, we have extensive web site work hooking into the database, and we need to encrypt credit cards. I added the .Net DLL to SalesLogix so that both the web access layer and the forms in SalesLogix can use the same encryption and decryption functions. |
|
That is a great example of using a .NET Extension from SLX. There are many cases like this that using a scripted plugin in SLX just wouldn't cut it, not to mention the lack of reuse from a scripted solution.
Thanks for sharing Jeff. |
|
|
|
Re: why not to use a .Net assembly in SalesLogic ??
Posted: 12 Jul 07 1:02 PM
|
Originally posted by Phil Parkin
Hi Ryan - it would be great to hear a few examples of cases where you have found it easier to use .NET than standard SLX tools. |
|
Hi Phil,
Some of the obvious cases where a .NET Extension would be beneficial are for things like:
- Too complex for scripting - or more easily or elegantly done in .NET. As you mentioned, the need for threading, integration with other systems, or just using the power of the .NET framework in a solution that makes it an easier task. Making use of 3rd party .NET components to make a job easier as well.
- The need for code reuse, as JeffW mentioned. Adding your code in a .NET assembly, instead of in a script plugin, makes for a great way to reuse the code in other areas, as well as in other systems (websites/services, other integrated apps, stand alone apps, etc)
- The need to better hide the code from prying eyes. Something that validates from other systems, encryption, generation of serial numbers or "keys" of some sort, etc. Anyone can fire up a script debugger and see all the code that passes through it. It makes more sense to add it into a .NET Extension (obfuscated) to keep things a little more "private".
- Lastly, it's just a whole lot more fun to code in .NET
There's definitely a right time and a wrong time to use an extension. You wouldn't want to try to do everything that way, it just wouldn't make sense. Just the same, it wouldn't make sense to *not* use an extension for tasks that are better suited for one either.
-Ryan |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|