11/25/2024 10:39:14 AM
|
| |
| 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 using the SalesLogix COM interfaces from external applications, such as SlxApplication, ClientObjix, etc. View the code of conduct for posting guidelines.
|
|
|
|
Allowing third party access to slx
Posted: 30 Jun 06 7:53 AM
|
fiogf49gjkf0d I'm somewhat emabarssed to be asking this, but...
We are hiring an outside firm (not slx bp) to create some internet apps for us. They will be using the data in our slx db -- both reading and writing. They are reluctant to do so directly and would prefer to go through some API. I have done some of this but have always had the slx client open so that I could use my code to call slx architect code in addition to what I was writing.
My questions are these: What should I tell them is the best method for interfacing with slx. (ClientObjix, Application, or other)? Where are the best docs for the recommended method?
Thanks. |
|
|
| |
| |
|
Re: Allowing third party access to slx
Posted: 30 Jun 06 9:44 AM
|
fiogf49gjkf0d SalesLogix v6 and higher has it's own OLEDB Provider. This will be what they need to use. They would just use standard ADO/ADO.NET to read/write to the database using this provider. That's about all there is to it.
There are articles on this site that discusses the connection string they will use from ADO/ADO.NET to establish a connection via the provider. Some of these should help: http://www.slxdeveloper.com/page.aspx?id=15
-Ryan |
|
|
|
Re: Allowing third party access to slx
Posted: 30 Jun 06 9:49 AM
|
fiogf49gjkf0d I would suggest that the use the SalesLogix OLEDB Provider. This will allow them to make an ADO connection and use standard ADO commands. The SalesLogix Provider will take care of Logging and Security. |
|
|
|
Re: Allowing third party access to slx
Posted: 30 Jun 06 10:59 AM
|
fiogf49gjkf0d I have told them that -- but they insist that they don't want to. Reason is something like this...
They need to insert an account. We (you and I) know that this will require an Account_UC field, an entry in the AccountSummary table, etc. They don't. They are looking for a high level API that would provied a function like the following
strNewID = InsertAccount(strName, ... ). That way, they don't have to worry about the inner workings of slx.
Does anything like that exist? or even close? This is being done in India so there won't be much of a chance for extended training or face-to-face conversations.
Thanks.
|
|
|
|
Re: Allowing third party access to slx
Posted: 30 Jun 06 11:18 AM
|
fiogf49gjkf0d There is no such thing for SLX. That is the problem with having someone who doesn't understand SLX develop something that will write to the SLX database and why the SLX business partner channel exists.
I've fixed *many* botched up systems and had to undo years of bad data because someone who didn't understand SLX built an application that didn't do data the right (SLX) way. Sure, something like what you describe would be great and prevent those kinds of meeses from happening. However, it just doesn't exist. If you are going to write code for SLX, you just need to understand all of those mostly undocumented tricks. Sad, but true.
That said, what I have done many times for customers that want to write their own code for SLX, but don't understand SLX's secret tricks (and don't care to learn), is build them their onw library to do exactly those kinds of things you describe. I'll wrap all the SLX inserts/updates/etc into a nicely wrapped DLL that they can reference and do things to their hearts content and not have to worry about all the internals. Know what I mean? I've done this many times and everyone sleeps better knowing the data is right, and my non-SLX customer can still do the development. |
|
|
|
Re: Allowing third party access to slx
Posted: 30 Jun 06 12:02 PM
|
fiogf49gjkf0d Give 'em the pimp hand and tell them to earn their keep. If they're that reluctant, tell them you'll pay them up until the point it touches SalesLogix, then you'll get someone qualified to take it into the endzone. If they don't like it they can take the dev training class like everyone else and who knows, may be able to cater to a niche market inside SalesLogix-land.
Personally when I think about all you have to go to in creating an account/contact (address records, account_uc, accountsummary, etc etc) I often wonder why it's not encapsulated in an easier to use interface. I mean take a look at the Insert Account/Contact stock SalesLogix code. Every single time you insert a new entity, about 5-6 tables have to be populated very specifically. If I could have an account without an address maybe doing it this way would make sense but since all of my ducks ALWAYS have to be in a row, why do I have to place them there myself? If I could omit one of the ducks that would be another thing entirely but the process is very rigid and does not allow ANY mistakes. Why even give people the chance to royally hose the database?
Ryan has the right idea with the library, and I'm surprised someone hasn't made any money off the idea. I doubt such a thing would get rolled into the OLEDB Provider any time soon either, so you could probably make a small fortune by the time it does. |
|
|
|
Re: Allowing third party access to slx
Posted: 30 Jun 06 12:43 PM
|
fiogf49gjkf0d Originally posted by Jeremy Brayton
I'm surprised someone hasn't made any money off the idea. |
|
Every customer has custom tables and fields that must be accounted for as well as different default values, different security, etc. I am not saying it is impossible but it sure isn't trivial.
As for the 3rd party vendor refusing to write to the database, I suggest finding another vendor. It is one thing for them to mandate that your company clearly document the requirements so the they can correctly handle the database transactions. It is another thing entirely for them to refuse to do anything without an API. Fishy at best...
Timmus |
|
|
|
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!
|
|
|
|
|
|
|
|