I am working on a project to integrate accounting data like receipts, invoices, etc from a Java EE system into Microsoft Dynamics GP 2010. The database is MySQL. Please share your thoughts on which which approach works best. I have searched around and there are 2 approaches: Integration Manager, eConnect via Web Services.
Thanks
In my opinion you have two legitimate options - eConnect via GP Web Services or eConnect via SQL Stored Procedures. I wouldn't consider using Integration Manager as it cannot be automated and requires someone to log into Dynamics GP before using it.
The most simple integration point would be to call the eConnect SQL Stored Procedures directly at the database level. For each eConnect integration object, there is a corresponding SQL Stored procedure. You simply call the procedure and pass it the proper values into its parameter. Creating an invoice in Dynamics GP, for example, can be done by calling the procedures for creating SOP Document headers, lines, and distributions.
On the other hand, if you are prepared to spend a little extra time installing the GP Web Services then you can integrate with that and maintain a service oriented architecture. Most of the same functionality is available via the web services but it is a subset of the features available in the eConnect procedures. In return, you get all of the benefits of a SOA architecture.
Ultimately it depends on your plans for overall architecture in your environment. Either method should work fine for your requirements. If this is the only integration into GP I might chose the more simple method of eConnect stored procedures. If you plan to integrate other applications into Dynamics GP you may want to take the time to invest in using the services.
Related
I want to integrate our Sales CRM dynamics system with another application. Approaches we are considering are using web api and webhooks.
Can we use webhooks without using an azure function/azure service?
what all are the challenges?
Is there any other better methods to pull data from Dynamics CRM?
What all things should be considered while doing an integration with Dynamics CRM system?
(I am new to Dynamics)
link followed:https://dynamicsninja.blog/2019/05/22/d365-webhooks-part-1/
If it's a relatively simple integration, using Power Automate might be your best bet.
https://flow.microsoft.com/
To answer your specific questions, though:
Can we use webhooks without using an azure function/azure service?
No. You'll need to use Power Automate, Logic Apps, or some other method to watch for changes.
what all are the challenges?
That's a pretty broad question, can't help you without specific things you've already tried.
Is there any other better methods to pull data from Dynamics CRM? What all things should be considered while doing an integration with Dynamics CRM system?
If you're just doing reporting (pulling data) then PowerBI is a good choice, otherwise it's the API for custom integration or Power Automate/Logic Apps for something that needs a little less customization.
If you realy want to have a CRM fully integrated i would consider to try
• Power Automate (as said before): it's a good way to easily connect several systems
• Azure Functions: Sometimes power automate is just not enough but with azure functions you can easily create some serverless code. I have some aazure functions that are triggered by receiving a message in a queue by power automate for example. You can make both work together and that what we have at work :)
The biggets challeng is the "know-how" I guess. A lot of people do not know it yet. Azure functions can be a little difficult at the beggining (even more if you want to use early bound classes for you CRM). With some time you will get it.
If you want do distribute your tool as a dynamics solution package which than should be added to an organisation without generating API token in azure and stuff like that i would suggest you don't pull data from dynamics (that way you need to authorize at the ms webapi with a token generated in azure and so on). Instead use web components and plugins triggered by core messages to push the data to your api.
Since ADC is provided by MS as SaaS to customers, is MS taking backups of the dataset and business glossary? If yes, how often and how can a customer get access to the backups for recovery purposes?
Unfortunately, there is no explicit backup/restore feature available for catalogs.
I would suggest you to vote up an idea submitted by another Azure customer.
https://feedback.azure.com/forums/906052-data-catalog/suggestions/33125845-azure-data-catalog-backup-feature
All of the feedback you share in these forums will be monitored and reviewed by the Microsoft engineering teams responsible for building Azure.
The closest way to achieve this with current functionality is to use the Azure Data Catalog REST API to extract all assets and persist them locally (and re import them manually later).
There is a sample application available that demonstrates this technique: Data Catalog Import/Export sample tool.
Dynamics CRM 365 Online has Telemetry to monitor application performance and usage. My understanding is it stores data in Azure by sending via Script and on this Alerts can be set in Azure.
There is a CRM solution Organization Insight which is used for counters like API faults etc. my understanding is that this solution stores data in CRM and not Azure.
Please help if this solution generated data can also be used for settings alerts in azure and if yes, how? Thanks.
Over a period of time different products, SaaS offerings, platform tools, O365 capability were introduced/evolving in and around the Telemetry space. Some are strong in broader horizontal features vs deeper vertical strengths. Upto you to decide based on functionality matrix.
Dynamics CRM using Application Insights - this is just leveraging Azure Application Insights to track Availability, Performance, Usage of our CRM online using AppInsights features. It gives you the power to utilize client side telemetry like user activities/metrics/exceptions/browser, Server side agent for on-premise logs similar to Event viewer/IIS logs, data export, Alerting mechanism & web hooks, custom query, visualizations inside Azure portal resources blade (slice/dice), predictive analysis, etc.
CRM in-house Organization Insights - this is inbuilt telemetry solution from Product team, not yet fully delivered (still with bugs & limited functionality for data consumption itself), but we can expect more features, options & utilities to explore more in future. These are missing today & thats what you are asking. You can download data, call MS to give you the exported data, but still Alerts & monitoring wont fit using only available odata support for charts. This covers a lot of useful Admin stuffs, like natively gives you all plugins, WF, API calls, user interactions, mailbox, storage data, etc within CRM.
Activity logging - this is in preview and MS saying it’s more than what we have in Audit today, gives you extra than CRM audit but less than what Org Insights providing, even less than AppInsights features. But I expect more functionalities here like Alerts, Monitoring, web hooks as this is across O365 platforms & available for Global admins.
I am looking for connectors/Middlewares that can be used to integrate any third party application with the widely used ERPs for eg: a. Oracle EBS b. Netsuite c. Sage ERP d. SAP ERP e. Microsoft Dynamics
Are there any connectors/Middlewares available that are recommended to use for this.
Any Help is appreciated
Mulesoft ESB has pre-built connectors for most of those.
I have a large customer who has used it at the core of their Netsuite integration strategy for a number of years.
How should data be pushed into CRM 2011 from another system?
I would like to pass the data to a web service.
I have thought of 2 options so far:
Create a custom entity and create records of this entity by calling the Organization service from the other system. A workflow can handle everything from that point.
Create a WCF service and host it somewhere. The other system passes data to this service and the service interacts with CRM.
The client will just pass us records, so validation must happen on the CRM side.
EDIT:
If the client is an old system (in Cobol or something) is it still possible to connect to the CRM service?
Just to expand on Predro's answer:
I have actually done both with CRM 4. I would highly reccommend that you create your own sevice for the client to call which in turn calls the CRM services.
This gives you an extra layer of abstraction for when things change later - and they will.
If your client calls the CRM services directly it will be difficult/impossible for you to change your internal data structures or move servers around in the farm. Esecially true if you currently use a singer-server infrastructre.
Also don't map the service you create directly to the entity data structure, use an intermidiate model.
So if you wanted the client to pass Account details in, have your service expect an XML document that you convert in to an Account Entity, rather than expose the Account Entity and have your client submit that.
The second choice for me is the best way to handle with this situation, because you can control and validate everything in your side. You can host the WCF service in the same server of CRM Dynamics or in another server with access to CRM Dynamics and interact with with CRM through CRM Web Services.
I think you don't have any better solution.
Assuming the client has a login to your CRM system, I would actually go with the option #1 first. Why?
You can still validate the data in the Pre-Validation plugin stage.
This is by far the easiest and fastest way to get going. Will things change? Maybe! But:
You are going to spend lots and lots of hours getting a custom WCF service up and running
Somebody has to deploy it
Somebody has to maintain it
Your client has to learn how to connect to a proprietary WCF service instead of saying "Here's a bunch of published info on how to connect to CRM's webservices."
It becomes a "hidden silo" of business logic instead of it all existing in CRM. Any good CRM developer would be able to work on option number one. Number two requires additional skills.
If it really does change over time so much that it needs its own WCF service, you haven't really wasted that much time. All your business logic would be ported from a plugin to the WCF service. But it is much harder to go from the more complex solution (#2) to the simpler solution (#1) if it turns out that you don't need it.
I promise you that your customer wants this done faster and simpler (cheaper) rather than longer and more complex (expensive).