You’re offline. This is a read only version of the page.
30
I am a .NET developer and a client has asked me to investigate how to get data into and out of Dynamics SL. They need to be able to get data from another system into dynamics, and get some data out of dynamics back to the other system.
I am not knowledgeable about Dynamics and I don't own the software itself. I am in an analysis/evaluation stage.
So far, I have not found much in the way of documentation online that would help me understand whether what I want to do is feasible. Is there an API for doing these kinds of things, or is this kind of thing normally done via direct access to the data? Any pointers to resources that might help me get started would be appreciated.
"... what I want to do is feasible"
Answer is almost certainly.
"Is there an API for doing these kinds of things"
Answer, yes and also "sort of"
"is this kind of thing normally done via direct access to the data"
Answer, probably as least as often as "API" type methods are used.
The Dynamics SL product uses Microsoft SQL Server back end with no product specific encryption or access control. So, you can definitely get direct access to the database assuming the end user's IT department is willing to grant you access.
The help documentation for the product has a section called "Schema" which actually does a really good job of documenting pretty much every field of every table. Table names and field names are fairly understandable just by their names (unlike some products that use things like just number codes for table names and things). Also there's a significant amount of consistency in field names, table relations, table and field purposes etc. across different "modules" of the product making it more efficient to become familiar with the database.
That's the good news about direct database access.
The bad news is, the last time I looked there were over 600 tables and at least as many views in the database and there is NO entity relationship diagram available and no referential rules are defined in the meta data of the database (i.e. no foriegn keys, cascading triggers, etc)
Other bad news; frequently the relationships and rules that look obvious and may appear to work initially are actually flat out wrong or are only correct under certain conditions but not all (i.e. NEVER link to a record in a transaction table in SL by the LineNbr field).
In the end, if you decide to hit the database directly, you will be COMPLETELY RESPONSIBLY FOR MAKING SURE THE DATA YOU ENTER IS "CORRECT"!
Regarding "API" integration... The product has GREAT integration and customization functionality. One feature along these lines that you should REALLY consider is something called "Transaction Import" (TI). This tool automates the process of reading a text file of data and using the data in that file to automatically "type" the data into any screen in the product. This tool uses a "control macro" script file to map and potentially manipulate the data in a text data file to a given screen. There's a tool that will generate a "template" version of this control macro file for you for whatever screen you select (even "custom" screens that were not originally part of the SL product) then you can edit that template macro file to meet your specific needs.
TI is extremely powerful and since it uses the exact same logic to enter and update data that is used when an end user enters or updates data, you can be sure that you CAN'T enter or create invalid data in the system when using this approach.
TI can be tedious and frustrating to get your macro scripts and data files just right at first, but usually once you've got them defined correctly, an average end user with next to no technical know-how can then run the import processes over and over without any trouble.
There's also anther tool called "Solomon Object Model" (SOM). This is a COM interface that lets you programmatically automate ANY Dynamics SL screen from any language that can be a COM client. The SOM API is fairly intuitive and with a day or two fo playing around with it, a good programmer should be able to sit down with a Dynamics SL end user and have the user tell them how they would import the data if they were to manually type it in and the program could then write the SOM code to automate that process.
Finally, there's an Application Framework called the Dynamics SL SDK. This is the actual set of object and API's that Microsoft (actually Solomon TLB, going back to the product origin) wrote in C (C++) and then gave to the Microsoft/Solomon VB/VB.NET programmers to actually write the Dynamics SL product itself. So, you can write programs exactly the same way that hte product itself was written. The result are programs that look, act and integrate with the Dynamics SL product completely seemlessly to the end user. NOTE! These tools do NOT enforce referential or logical or even business data integrity! They may make it easier for you to write code that will enforce these things, but it will STILL be YOUR JOB to write code that enforces these rules!
Hope this helps.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
290,524
Super User 2024 Season 2
#2
Martin Dráb
228,469
Most Valuable Professional
#3
nmaenpaa
101,148
Share
Report
All responses (
Answers (
