05-11-2011 03:41 PM
We're having troubles fine-tuning ERPLink/Sync and finding the line between syncing up-to-date data (mostly Invoices) and performance. With 7000 active accounts, its more of an impossibility for us to complete a full nightly (/n switch) and still have a usable system when the Sales team comes in every morning.
(As a side note, with MAS500 and SLX sharing the same database server, apparently Windows-Authentication clients are locked out of MAS500 during the sync . . .)
My workaround is to use Dynalink to import Payment and Invoice headers, and then create a dynamic group off of Recent Activity for both of these (Last XXX days of Check Date or Invoice Date).
Anybody else have suggestions or pointers?
05-12-2011 11:26 AM
We've ended up using SSIS for our MAS --> SLX integrations. It's fast, flexible and very robust. But if you trying to sync a lot of data from MAS to SLX and you're having trouble completing the sync in a reasonable amount of time here's what we've done in the past where Dynalink was kept as the solution.
1. Indexing SalesLogix Tables - Sometimes the huge delay was just in the way that Dynalink was retrieving the record first to determine if it existed or not before deciding whether to update or insert. When we saw what was happening through the profiler we were able to add indices which made a big difference. (i.e. Refreshing 12K accounts + 20K Order Headers + 100K+ Order details went from 11 hrs to about 2 just by adding some key indicies.
2. Filtering your data from MAS - Your on the right track to filter the data coming from MAS if you can. There's a few gotchas though to watch out for.
- Check Dates and Invoice Dates may cause you some grief since I've seen users enter this information wrong and you end up missing records because the user incorrectly entered a date way in the future or way in the past. It's best to use LastUpdate Date where you can.
- Becareful on how you construct your queries for MAS data especially for Invoice Headers and Detail. If you end up using a query which does not use the indicies in MAS 500 the cost of retrieval can sometime out weigh the benefit of processing a smaller result set.
3. Put Dynalink on it's own box (not necessarily a server machine). We found that Dynalink seemed to run at a low priority so having it on a machine that was being used for other services and processes tended to slow down the runs significantly.
Hope this helps.