Is there any possibilities to connect Drupal Commerce (or Ubercart) with SAP Business One ?
Disclosure -- I work for a company that provides SAP addon solutions and we have a product called B1Integration which is a SOAP-based system you can use to extract and import data into SAP Business One. Visit www.beabetterbusiness.com for more information. Not sure if that's allowed via SO T&C but there you go. --
There are also several other SAP partners like us who have their own integration platforms.If you wanted to tackle it yourself then I recommend looking at SAP DI Server, and not SAP DI API, as the DI Server is more suited to external data exchange (our product is based on the DI Server) since it uses an XML-based import format. There's also a free tool from SAP themselves called the B1Webservice which exposes SBO Objects via a Webservice, although it's not supported officially and is a bit clunky. Check out www.scn.com and go to the Business One section.
http://scn.sap.com/docs/DOC-7699
Hope that helps!
There are several ways to do that, mainly you can use SAP Business One DI Server or DI API. You can search for documentation about how to use them os SAP.
When talking about web (Drupal) SAP Business One recommend DI Server, but you can use DI API without problem
Related
We have a mobile application made in VB.NET for Windows CE/Mobile smart devices for shipping/reception operations in a warehouse. This application connects to a SQL Server and extensively uses stored procedures. Since Windows Mobile devices are discontinued and replaced by Android devices, we have to convert our solution to Android, using Visual Studio's Xamarin and C#.
I'm a newbie at Android programming. Is there a way we can connect directly to a SQL Server instance and call a stored procedure from Android? I made some searches and people says it's better to call web services as an intermediary between Android and SQL Server. Is it the best practice?
Thanks for your insight and help
Upgrading Legacy applications can be incredibly complicated depending on the technology and frameworks used.
The first thing I would suggest taking a look at is the Architecture documentation Microsoft produced for Xamarin and Cross-platform frameworks which you can see here
Typical Application Layers
Data Layer – Non-volatile data persistence, likely to be an SQLite database but could be implemented with XML files or any other suitable
mechanism.
Data Access Layer – Wrapper around the Data Layer that provides Create, Read, Update, Delete (CRUD) access to the data without
exposing implementation details to the caller. For example, the DAL
may contain SQL statements to query or update the data but the
referencing code would not need to know this.
Business Layer – (sometimes called the Business Logic Layer or BLL) contains business entity definitions (the Model) and business logic.
Candidate for Business Façade pattern.
Service Access Layer – Used to access services in the cloud: from complex web services (REST, JSON, WCF) to simple retrieval of data and
images from remote servers. Encapsulates the networking behavior and
provides a simple API to be consumed by the Application and UI layers.
Application Layer – Code that’s typically platform specific (not generally shared across platforms) or code that is specific to the
application (not generally reusable). A good test of whether to place
code in the Application Layer versus the UI Layer is (a) to determine
whether the class has any actual display controls or (b) whether it
could be shared between multiple screens or devices (eg. iPhone and
iPad).
User Interface (UI) Layer – The user-facing layer, contains screens, widgets and the controllers that manage them.
Now you could just simply use the System.Data.SqlClient assembly and fire off stored procedure runs against your database. However a more common approach would to create an REST Api that sits in-between your client and your back-end services.
You can download a handy E-book created by the Devs over at microsoft that will show you some common enterprise patterns to use for Cross-platform technologies like Xamarin which can be found here
Here's one such example of the kind of patterns those links refer to.
You can also find an overview of various web services that you can use at this link
The options it gives you an overview of are:
ASMX
WCF
REST
So plenty of choice, but depends on your current approach.
I'm currently searching on the web to find a good PHP Framework for:
SQL Server 2000
can manage stored procedures calls that return more than 1 recordset at a time (for example mssql_connect)
can use multiple database at the same time (Ex: Master and Client databases)
For now, I have a short list of candidates:
CodeIgniter
Kohana
Zend Framework
Fuel PHP
CakePHP
Others ???
Our goal is to be able to connect to a Master database for login purpose and then, connect to client database for specific data.
From what I can see, only CodeIgniter seems to be able to achieve those goals.
My advice is to go with Codeigniter. There is an amazing community both in the irc chat channel, forums and it has the best documentation bar none.
You get your project done and when you have, then you look at any other alternatives to do anything you want done better. As there are things the other frameworks can do better than Codeigniter.
Kohana is a great framework with active development. I would recommend it, along with an ORM module called Leap that supports multiple different types of databases (including MSSQL).
Apologies for the newbie web service question -
I am trying to create a webservice that has a list of methods to perform read/writes to a database. An example function will be of form -
CreateNewEmployee(string username, string employeeid, string deptname)
I created a webservice in .net (asmx) that has the above mentioned webmethod. In that, I open the connection to the data base and do an insert in to the database and then close the connections. Is this the right way to design the web service call?
Should I instead be passing an object instead of multiple parameters?
Any pointers toward best practices when trying to create a webservice that writes data into a database?
To add some more information
We would like to have web services since it might be reused by many different applications within the organization (both web and desktop).
We are also planning to create an environment where users can use these web services to create data mashups.
Thanks,
Nate
Yes - pass objects vs large parameter sets. Also, have you considered WCF if you're in a .Net environment? If you look at how ADO.Net Data Services (formerly Astoria) works, it will put you in the right direction.
Quoting from the winning answer to this SO question:
Web Services are an absolutely horrible choice for data access.
It's a ton of overhead and complexity for almost zero benefit.
You can read the rest of the discussion there.
Edit: One excellent approach to having a common data access functionality that can be shared by multiple applications - web, desktop, service - is to create a Visual Studio project that compiles to a DLL. Each solution that wants to use the data access functionality references the DLL, which can deployed to the GAC or some other central location, or just added to the project's bin folder. Alternately, in order to be able to step through the data access code, the data access project can be added to a solution.
This is a very common practice in large enterprises, where many back office applications share common functionality. It is used not just for data access, but also for other services such as logging and authentication/authorization. Some divisions create a set of these DLLs, which they refer to as their "framework". It ensures that every application will have the same functionality and the same business logic, and that there is a single place for revisions to be made that will affect all of the applications. This is a similar benefit to using web services, but it avoids the overhead and performance hit of web services.
I'm in the process of designing an application that would tie into the database for multiple e-commerce stores.
I have the general business logic down but the problem is, I have no idea on the most painfree and effective way to do the data integration. I know how to access my own databases, but this is something I always just left to my hosting provider to handle the backend and I just developed the interface
Can someone point me in the right direction on this? There is a large emphasis on ease of installation. So my customers (once I get them) should be able to very easily integrate their system into my app.
RESTful web services are what many folks do for this.
Start here: http://en.wikipedia.org/wiki/Representational_State_Transfer
Then revise this to be a more specific question.
You might need to look at direct VPN/SSL connection from their server to yours.
Is it possible to access the database backend of a sharepoint server? My company uses Sharepoint to store data and pictures of various assets. Ideally I would be able to access the data and display it in my application to allow users both methods of access.
Before I go talk to the IT department I would like to find out if this is even possible?
Edit: From rails on linux? (Yes, I know I'm crazy)
Agree with Adam. Querying the Sharepoint Database is a big no-no, as Microsoft does not guarantee that the Schema is in any way stable. Only access the database if there is really no other way.
As for Sharepoint, usually the Lists.asmx Web Service is what you want to look at first.
http://www.c-sharpcorner.com/UploadFile/mahesh/WSSInNet01302007093018AM/WSSInNet.aspx
http://geekswithblogs.net/mcassell/archive/2007/08/22/Accessing-Sharepoint-Data-through-Web-Services.aspx
yikes! :)
look at the web service and .net API before going direct to the database. i've used both and they provide plenty of flexibility (including building your own web services on top of the API if necessary). API for on server clients, web services for off server clients.
Just a small comment. Never ever go to the database direct. If there is no way to do it via published and supported API's, then there is no way to do it. End of story. This applies even to when you are "just reading data", as this can still cause significant issues.
Just to support the above if you ever take a look at the SQL tables that sit behind SharePoint you'll realise why its not recommnded or supported to access the database direct. MADNESS!