I need to insert some fields of data (example: Customer Phone etc) from outside(Externally) into the already developed/working (Installed) ERP Invoicing application. When I open the ERP application those fields should automatically appear in the application for the particular order in the form. Currently the the external data is entering manually into the ERP application. I need to integrate from the different place to ERP Application using some another application, like C# Windows Application. We can access ERP database. How can I approach this for the solution to the problem using C#/windows application externally.
I am not sure what approach you used for Integration, but as it seems from your question that you have enough knowledge about their database structure and flow of data you can directly write to the tables to reflect the updated information in that ERP.
But this is not a recommended approach to integrate with any ERP, by directly interacting to their database tables, even if you have access to them and you very well understand the data flow. Integration to any ERP should only be done through API's provided by that ERP, or through some connectors available in market which are recommended by the ERP vendor.
You should look for an API or interface your ERP application provides to integrate external applications and/or modules, otherwise, if you have enough knowledge of how this ERP works and underlying database structure, than you can directly interact with the data...
Related
I'm trying to use Entity Framework Core with SQL Server (not SQLite) in a Xamarin forms app but I just can't figure it out! All tutorials explain how to use EF Core with sqlite! Are there any clear documentation or tutorials?
About connect to a Remote DataBase in Xamarin.Forms, I find one article that you can take a look:
https://xamarinhelp.com/connecting-remote-database-xamarin-forms/
You may be wondering why you couldn’t just connect directly to a database from your mobile app? The main reasons are:
Security
You don’t want your mobile client apps to have a database connection string with a username and password in it. It opens your database up to anyone. You can create a user with read only permissions and only allow access to certain tables, but they could still see all data in these tables. On an API, you can implement additional security checks and have authentication based on OAuth or an existing user management system.
Performance
Database connections weren’t designed to go over high latency connections. It is likely your database connection would keep dropping, forcing you to reconnect every time.
Control
With an API you can control the flow of data to and from your database. You can implement rate limiting, and monitoring of all of your requests. If you need to change business logic, or even what database or resources are used via each API request, you can do this on the server, without having to redeploy a mobile app.
Resources
With an API, you reduce the need for server resources. While you may have to setup another server to handle an API, the REST API is designed to be stateless and efficient. Scaling to many users in the future is easier with an API.
I am asked to develop (from scratch) a REST web service in .NET that wrapps calls to various data sources:
Databases (SQL, DB2, Oracle, etc)
Other web services (SalesForce, Microsoft CRM, etc)
Flat files
etc
In the end, we would display this data in web UIs : grid, charts, etc. Other features include: caching, usage monitoring, user roles management. And the idea would be to query this web service with a syntax similar to Open Data.
The data sources configuration would be done in a database, or in a configuration file.
Ex: Data source "DS1" is of type "Database" to server "srv001" on database "db001" and gets data from stored procedure "sp001".
Before I start developing that from scratch, I first googled to see if an existing stardard component exists for that. But I couldn't find any.
=> Is there an existing tool on the market that does it out of the box (or close to out of the box) ?
Thank you
Alex
There are lots of ways to expose data through a restful interface using .NET
For exposing a data source as a service you should use OData.
For combining various sources, as you mentioned, as your own mashup service use Web API
If your service is only going to be used internally I would use WCF which will be the most performant and easy-to-work-with option.
I am developing an .net Winforms application and I need to secure the connection to the sql server 2008 database. I plan to create a webservice as a middle tier that will handle the authentication and that will provide data manipulation. Is there a better way to go with? Does .net have components or tools for that? What is the best technique?
Any info would be appreciated, thanks.
Define "secure". Obviously you wish to restrict access to data to users who really need that data. However, more information about the architecture is needed; is this an in-house app that will only ever be used inside a (secured) LAN, VPN or hosted environment? Or is this an app used on computers you do not control, that will transmit data over the Internet? How much security you need depends on what types of users will be using the software, from where, and how sensitive the data is.
MSS has pretty good security built-in. You can tie SQL users to Windows domain accounts, you can restrict "securables" (tables, views, SPs, etc) in myriad ways based on user or role, etc etc. I would first look at those capabilities, and seriously consider taking advantage of them in your security plan. One SQL user defined for use by any user of a particular piece of software, which has the permissions to do anything the software may require, is simple, common, and highly insecure.
If that's not good enough, or you want to fully abstract your data layer (for instance, if you need the software to be able to be pointed at any DB type from MSS to Oracle to MySql), then it might be a good idea to implement a Repository model with a service proxy. Like Brian, I encourage you to have a look at WCF. A WCF service is highly configurable, and can provide for independent authentication and for encryption. A well-designed WCF service will be very secure indeed.
Behind the service, you can implement a Repository pattern, which abstracts the details of how data is retrieved from the data store and exposes simple methods that return objects containing the data you want in a ready-to-use form. Now, your service methods will just map 1:1 to Repository methods, possibly with some translation to DataContract-serializable objects instead of the richer domain model available on either side of the service.
Have you looked at building a service tier, using WCF? WCF can bring a whole new layer of abstraction and security from the actual physical database.
WCF also allows you to use more secure bindings than a traditional web service allows, with built-in logging.
Also, check out this book sometime if you want a really good read on .NET Security:
The .NET Developer's Guide to Windows Security by Keith Brown
I have a developed a application that is gonna to be used at multiple places.
So how should i maintain one database for all?
Or is there only one way of using remote database for this software.
If i use remote database, i am facing problem with loading controls in forms.
Please Suggest Solution.
Thanks
Typically you'd design a system leveraging multi-tiered architecture, which often consists of:
Front-end user interface
A database back-end
Middle tier/business layer that let's your web pages access the database and provides additional business logic (perhaps a web service?)
You don't give much to go on as far as details go, but it seems like you have several physical locations that need to access a single database. So you can:
Develop an (web or desktop) application that handles the front-end UI and the middle tier (which will access data and do other stuff)
Develop an application that handles only front-end UI, but calls a web service that accesses a database and does other stuff. In this case, you may have several locations with different front-end applications that consume the same centralized web service.
I have an application that runs on a server and uses SQL server 2005. If I wanted to make this application integratable with other systems such as a CRM, what would be the best strategy? My idea was to create a public Web Service with authentication...does this sound like the right approach?
Any idea's would be appreciated.
Yes, Ideally all integration is done using industry standard communication protocols, requiring some middleware that links these standards. Ideally these protocols would be something like a webservice as you say where the API ensures validation all data imported into your system.
Most basic integration between systems means Transfer of Data between systems. You can either choose to build an API to which you or others provide the middleware to connect. Or depending on the nature of the applications, you your case CRM, it may be worth ising this same API to build an Import/Export mechanism where users can just just Export their data into xml, CSV and also import their data, building a nice interace to map any CSV format to your own fields is a nice touch and means less technical users can perform non-automated tasks.