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!
|
|
Which Import Method To Use.
Posted: 24 Jan 07 5:09 PM
|
fiogf49gjkf0d I'm not sure which method is best for this specific situation: An ongoing production load from an external database system into a SalesLogix 6.2 database. The actual import would be run every week and would involve complex updates and data roll-ups to the various levels in the Account-Opportunity-Product Instance hierarchy. My thoughts are:
1. Use KnowledgeSync
2. Use SCRIBE
3. Write a custom .net application.
Any thoughts would be most welcome.
|
|
|
| |
|
Re: Which Import Method To Use.
Posted: 24 Jan 07 6:42 PM
|
fiogf49gjkf0d Everthing I do is custom programs.
I have large complex imports running at several different sites. I start with Scribe 5+ years ago but had to which to custom programs, written in VB6, because to overcome Scribe performance issues.
|
|
|
|
Re: Which Import Method To Use.
Posted: 25 Jan 07 3:31 AM
|
fiogf49gjkf0d Hi Robert
Another product is Inaport, from us (www.inaplex.com)
Sage sell Inaport as the recommended import/integration product for the Sage CRM familiy of products (SalesLogix, CRM, CRM.com), and also use it as the basis for the Sage migrator product which is used to migrate CRM systems from one solution to another.
Inaport will give you:
* powerful data transformation
* sophisticated matching for update purposes
* a UI that lets you preview the effect of your transformations before import
* ability to print the profiles for documentation purposes
Any questions, please ask.
Regards
David Evans
www.inaplex.com |
|
|
|
Re: Which Import Method To Use.
Posted: 25 Jan 07 10:39 AM
|
fiogf49gjkf0d Thanks all.
I am still in favor of doing our own .net app for this purpose. But I'll give all alternatives a fair shake. And that now includes Inaport which looks very interesting. I looked at the Inaplex site and am requesting additional info.
Thanks again.  |
|
|
|
Re: Which Import Method To Use.
Posted: 26 Jan 07 12:13 PM
|
fiogf49gjkf0d We did a custom C##.NET app for a client to do this. In fact it was started by someone else and we had to pick up the pieces...
Hindsight.. I'd not go that way again. I'd use something like Task Centre and buld teh inntegration that way.
--
rjl |
|
|
| |
| |
|
Re: Which Import Method To Use.
Posted: 29 Jan 07 10:08 AM
|
fiogf49gjkf0d Ryan,
Thanks again. Orbis's Task Center looks very interesting. It may not fit my current project but seems very interesting for a number of other possibilities. I'll research this add-in appl. Does anyone have hands-on experience with this product?
|
|
|
|
Re: Which Import Method To Use.
Posted: 29 Jan 07 1:57 PM
|
fiogf49gjkf0d No problem. It does look nice, although I've not used it myself. However, I'd not consider it an option for an import. |
|
|
|
Re: Which Import Method To Use.
Posted: 29 Jan 07 2:04 PM
|
fiogf49gjkf0d Here's my 2 cents....
1) Knowledgesync isn't meant to be a data import / ETL tool. You could probably do it, but I'd not recommend it since there are by far better tools to get the job done.
2) Not a fan of Scribe. Don't care at all for it.
3) While this isn't a *bad* route, per se, it isn't a very smart one, unless you make things generic enough to get some reuse out of what you build. Not a good idea to spend time writing throw away code for every import you do, but if you have a process that you like to follow for imports and you can build a geneic tool that you can use to complete steps in that process, then it's not a bad route to take.
4) I've always been a fan of SQL DTS & SSIS. The version of SLX you're using will either make this an easy route or an impossible one. As long as you're on SLX 6.2.3 or higher then this is a very good route to take IMO. Although, many that take this route will get caught up in writing everything as Script tasks in the package and this IMO defeats the whole point in using DTS/SSIS to begin with. Use real transformations, not scripted tasks. The point here is to let the tool do all the work for you, without you needing to write any code. 
-Ryan |
|
|
|
Re: Which Import Method To Use.
Posted: 29 Jan 07 2:26 PM
|
fiogf49gjkf0d Ryan,
This has really turned into an interesting thread, and I'm learning a lot from it. And thanks to all for the advise and opinions.
Regarding your #4, I've used SQL's DTS in the past for non-SalesLogix projects. Its not easy to use in some cases (as you point out), but can do the job. Only I'm concerned about making sure that imported data is logged correctly for synchronization. I'm not sure how to do this in DTS. Any pointers?
Thanks again.
|
|
|
|
Re: Which Import Method To Use.
Posted: 29 Jan 07 2:54 PM
|
fiogf49gjkf0d As long as you're using connections via the SLX provider (and you're on 6.2.3 and higher due to some bug fixes that corrected a couple of issues that created the need for some tricky workarounds) then there are no special hoops to go through. |
|
|
| |
|
Re: Which Import Method To Use.
Posted: 31 Jan 07 6:47 AM
|
fiogf49gjkf0d Originally posted by Ryan Farley
No problem. It does look nice, although I've not used it myself. However, I'd not consider it an option for an import. |
|
In general, I agree (Oh yes.. I do have hands-on experience w/TaskCentre . However, if you have a "workflow" scenario, Task Centre can server as the "engine" to drive a DTS based import (or other custom import operation) very well.
--
rjl |
|
|
|
Re: Which Import Method To Use.
Posted: 31 Jan 07 9:17 AM
|
fiogf49gjkf0d My 2 cents: I really like to use DTS for imports, especially now that you can set the slx provider and db up to auto generate the id's. It's much nicer, and generallly it is very fast. |
|
|
|
Re: Which Import Method To Use.
Posted: 14 Feb 07 7:58 AM
|
fiogf49gjkf0d Robert,
I'd recommend Inaport. We use it extensively, with ad-hoc, hourly, daily and weekly import routines. It’s very powerful, yet even as a not programmer I can manipulate the data. We even extract data directly from SalesLogix, manipulate this and then re-import back into SalesLogix.
http://www.inaport.com/
Jason Rainbird |
|
|
|
Re: Which Import Method To Use.
Posted: 22 Feb 07 8:58 AM
|
fiogf49gjkf0d Thank you all. I'm still going to investigate each of these methods in an honest fashion. We have numerous projects which will call for different solutions, and I'd like to master a number of possible solutions for future work. DTS, Scribe, and Inaport now go to the top of the list. I'm also going to look at Dynalink as its a Sage product. Sorry I haven't been around for a few days. I was out a one of our client sites. |
|
|
|
Re: Which Import Method To Use.
Posted: 23 Feb 07 11:32 AM
|
fiogf49gjkf0d Hi,
Its funny, I too did not like scribe, wrote my own stored proc to take data from a web lead - real-time from our bond trading site and moved it into SLX. KnowledgeSync then kicked in and sent an email to the trader to follow-up. For my newest client I used a tool "Customer FX Transformation Tool Kit" from Ryan's company and love it. The entire solution use a SQL DTS Job (SQL 2000) and runs flawlessly. It was very easy to learn, priced very reasonably, and because it integrated into my SQL server, tweaking the code is simple. Put this on your short list too.
Paul
|
|
|
|
Re: Which Import Method To Use.
Posted: 23 Feb 07 12:29 PM
|
fiogf49gjkf0d This "Customer FX Transformation Tool Kit" also sound very interesting. Thanks for the info.
And Ryan, if you see this, could you please send me the specs and pricing for this product. I will definitely include it in my research. I like the idea of making use of the DTS facility.
Thanks again.  |
|
|
|
Re: Which Import Method To Use.
Posted: 06 Mar 07 11:56 AM
|
fiogf49gjkf0d TaskCentre is Business Process Management (BPM) Suite. Its a direct alternative to ksync and is very popular with SLX partners and customers globally. There are a number of reasons why this is the case but please speak to a SLX partner that already provides TaskCentre as they will give you a good independent overview of the product. Alternatively, visit www.orbis-software.com/contact to find your local distributor.
Regards,
spencerpc
|
|
|
|