This is more of an architectural question rather than anything code-related. I'm working on a project to auto-create invoices in QuickBooks using data from our ERP, in order to speed up the process of adding that data. It seems that it is a requirement that in order to access data within the QuickBooks company file directly, you need to use the SDK (which actually opens the file using a QuickBooks application instance). Since my application will need to access two company files depending on where the request came from, I can't keep it open, and this opening/closing adds 15ish seconds to each request.
Why is this a requirement, does anyone know? Is there another way to directly access the data and bypass the massive overhead of the QuickBooks application?
Thanks!
Why is this a requirement, does anyone know?
My understanding (based on a really old forum post by an Intuit developer) is that the way the SDK works is by using a GUI message pump Windows COM call to push data to QuickBooks.
No GUI present = no message pump = no connection to QuickBooks. Thus, you need the GUI components of QB in place.
Is there another way to directly access the data and bypass the massive overhead of the QuickBooks application?
No.
If it's a problem, consider batching your requests, queueing them up, and sending more than one at a time in a batch. This is what the Web Connector (and most other QuickBooks integrated apps) do to avoid this issue. It's very, very rare that an application truly needs real-time connections to QuickBooks (and be careful if you think you do - QuickBooks is not a great candidate for real-time access to data - there's a lot of things that can lock you out of QuickBooks so you have to be careful if you're building an app that assumes you'll always be able to connect to it).
Related
I'm trying to help a client who has a web application (ASP/C#) that integrates with Quickbooks via the QBXML SDK.
I want to open up a connection to an already active QuickBooks instance in a user session.
The relevant code in question:
if (rp == null)
rp = new RequestProcessor2();
if (!connected)
{
rp.OpenConnection2("IMS", "Internal Management System", QBXMLRPConnectionType.localQBD);
connected = true;
}
if (xticket == null)
xticket = rp.BeginSession(cfg.qbfile, QBFileMode.qbFileOpenMultiUser);
As is, this will attempt to launch a new instance of Quickbooks via DCOM, which is not a viable option. Following the QBSDK documention, I attempted to pass null to BeginSession's first argument, which should use the open qbw file.
However, instead of the expected action of connecting to the running instance of Quickbooks, it launches a new instance, eventually yielding the error:
"If the QuickBooks company data file is not open, a call to the "BeginSession" method must include the name of the data file."
The IIS AppPool running the web app uses the same user as the Quickbooks instance I'm trying to connect to.
This was all set up by a third party who is no longer available, and, of course, they left no documentation whatsoever on how this system was supposed to work. Any assistance would be welcome.
I'm trying to help a client who has a web application (ASP/C#) that integrates with Quickbooks via the QBXML SDK.
Unfortunately, this approach will not work.
It's a well-known limitation of QuickBooks that:
QuickBooks has to be running in the user session you're trying to connect from
QuickBooks has to have access to a GUI (it uses a GUI message pump to function)
Because your web app is running in from within IIS, neither of those two criteria are met, and connections to QuickBooks will fail. You should be using the QuickBooks Web Connector instead.
I want to open up a connection to an already active QuickBooks instance in a user session.
Unfortunately, QuickBooks won't allow this.
I managed to create an acceptable workaround to my problem, for anyone trying something similar. (Which, honestly, I don't recommend. I'm working with legacy code here.)
First, a brief overview of my research:
The QBXml interface with QuickBooks uses COM requests in order to communicate. Now, for whatever reason, whether design, bug, or limitation in COM, Quickbooks cannot communicate across LSA Logon Sessions. In practice, this means that the same console session that Quickbooks is running under must also run the QBXml code. Additionally, both Quickbooks and your application must have the same UAC elevation status.
I found no way to get IIS to reliably launch Quickbooks. The individual who setup this system before me managed to do so through some very... unorthodox methods. It was incredibly flaky, and the cause of multiple issues.
Regardless, I did manage an acceptable workaround, in the form of IIS Express. IIS Express can run under a standard user session. As such, running both Quickbooks and the web app (through IIS Express) under the same Logon Session allowed them to communicate successfully.
It is not a permanent solution, as there are drawbacks to running a service such as this in a standard user paradigm, but it is an acceptable workaround, and will allow my client to run their business while we refactor. I plan to first decouple the portions of the app that communicate with Quickbooks, moving them into their own codebase. This will allow the web facing portions of the app to operate in a more standard manner, and communicate with the QB integration code through a more reliable means than COM calls.
Thanks to Keith Palmer for helping point me in the right direction.
With CloudKit, you can focus on your client-side app development and let iCloud eliminate the need to write server-side application logic. CloudKit provides you with Authentication, private and public database, structured and asset storage services — all for free with very high limits.
You cannot upload any code to run on Apple's servers?
I've heard it being compared to Google App Engine and other cloud computing platforms, but without the ability to run your own code, isn't the whole thing pretty limited and not really comparable?
For example, if I want to build a news app which periodically pushes stories on topics that the user is interested, then this can't be done just using CloudKit because I would need scheduled jobs and data processing on the server.
Any thoughts?
Server-side
As you said CloudKit doesn't allow server-side code.
But there are possibilities.
Crons
You don't want to connect to the iCloud Dashboard everyday in order to perform the push by adding a record. One solution here is to code an app on a mac server (I guess mac mini as server will become more popular with CloudKit) that add a new Daily CKRecord every day.
Subscriptions
Subscriptions concept is that the client registers for specific updates. You can create a record type called Daily for instance and make users register to it. You should check the Apple documentation and WWDC14 videos (even if Subscriptions are not detailed, it's a good start point).
The good thing is push notifications are linked with the subscription concept. So basically you say: Send my a notification for each new CKRecord of type Daily added.
BaaS party
What is the point for using CloudKit (vs Parse and other?)
Price: CloudKit has a really nice pricing
Ready to go: 2 clicks inside XCode and you are ready to go
User consistency: you get free user login for all his devices through their iCloud account. With a very good privacy system. And you can get relationships with a smart system.
But:
You are stick on Apple platform. We don't even know if we could export the data..
Only data-centered for now (no server-side code)
The CloudKit dashboard is too limited
The future
CloudKit is still pretty new. At the WWDC some guys behind it made me understand that they are still heavily working on it. My bets are they are working on 2 important points :
Server side code execution through remote scheduled tasks
CloudKit for Analytics (Visualization side)
Edit: Apple guys are fully aware and concerned about the lack of web access for the data. It means that one day it may be accessible from other platforms. I read in a comment that Apple probably would have bought Parse if CloudKit wasn't better, AFAIK they tried to buy Parse (skills buy it's said, but we don't really know).
Update WWDC15
CloudKit is now available in JS and some dashboard are available now. Wait and see.
Update February 2016
CloudKit Now Supports Server-to-Server Web Service Requests
Web Services Reference
In some cases, we do not need server-side logic, and just storing static data can cover all the usage scenario.
In this case, it would be very helpful if there's a free accessible storage that you can store something. CloudKit provides such stuffs rather then full service platform.
Yes it is limited. Anyway can be useful for some people. For example, your case actually can be supported CloudKit. Though CloudKit is just a static storage, it support subscription. Which monitors a set of conditions and pushes the event notification to client. It's fortunate that the only background job feature supported by CloudKit is just what you need.
Anyway, if you need more, then you might need to consider full fledged servers. Usually simple web services with simple server-side code execution support are also limited.
You cannot upload any code to run on Apple's servers?
You can and you can't. You can't upload code / SOAP based web services to the server, instead of it you can upload / store observers on the server, called subscription.
whole thing pretty limited and not really comparable?
I would say in CloudKit and in MBaas client communicates with server though a more narrower more robust interface: you can not upload exotic web service to do XML parsing, database manipulations and based on it trigger push notifications, but RestFull architecture allows you to perform the 4 basic operation on the data store, and with subscription client can get notified about INSERT / UPDATE / DELETE operations performed on tables.
I think MBaas is just the next step in evolution of server - client architecture. First it seems it is limiting, but you can do all as in SOAP based web services world. Development is extremely fast / scalable / comfortable to use and easier to control things like permissions / setup, maintain server, security needs almost no effort.
Believe it or not, you can actually get REALLY far with this approach.
I've not used CloudKit, but I can describe for you my application stack:
AngularJS (or your favorite client side HTML rendering framework): A single page will host a series of templates/controllers selected by the router and driven by users changing the anchor to select which page they're on.
Firebase.io (or your favorite cloud storage): Any dynamic data goes into the cloud document store. The controller needs to load the data and render the template on the client, and when the data changes, send the data back. This also provides the authentication and authorization as well, since you can limit access to the data.
Now you need a place to serve the HTML/CSS/JS/images... which requires no 'server side code execution', just a web server where you can put the assets.
Using this technique you could store all the user's topics in the database for that user, and when the page loads, go and aggregate all the sources for those topics (also stored in the database) completely client side. There's nothing in your example application which actually requires server side execution that I can see, so long as you have cloud storage which will provide you with authentication and authorization services, and a 'dumb' web server for serving up static assets.
CloudKit isn't a full-fledged web hosting service. Instead, it's an SDK for iCloud. You shouldn't be putting a web site up there, just storing user data that you may want to use in multiple applications or platforms.
iCloud APIs enable your apps to store app data in iCloud, keeping your apps up to date automatically. Use iCloud to give your users a consistent and seamless experience across iCloud-enabled devices.
I've just begun to read the QB Developer documentation and have come to the conclusion that to write a web-enabled application that will sync/remote backup QB files between two machines over the Internet, that the QBWC is the 'approved' way to accomplish this task. The .NET application samples in the QB SDK (V12) are not using WCF but WSDL and SOAP.
But before I commit to going that route, I am asking if anyone has a better approach. I'd prefer to use WCF and MS Sync Framework, but I don't want to head down that road if it will mean using a cannon to kill a mosquito.
Thanks
You really hinted at two separate goals here, so I'll address each specifically:
... remote backup QB files between two machines ...
If your goal is BACKUP then the Web Connector is certainly not the answer. The purpose of the Web Connector is to enable integration between QuickBooks and web applications, via the QuickBooks API/SDK. Since not all data stored within QuickBooks is accessible via the API, the Web Connector is not appropriate for backup. It is impossible to get a complete, accurate backup of the entire QuickBooks data set via the Web Connector.
On the other hand...
... web-enabled application that will sync ...
If your goal is to allow integration/sync of data between your web app and QuickBooks, the Web Connector is a decent solution. Yes, it uses SOAP (with a grand total of only about 5 very simple methods). No, you can't use WCF/anything else without writing your own version of the Web Connector.
If you add more details about specifically what you're looking to do with specifically what data, you'll probably get some better answers and suggestions about approach.
I am new to iOS app development and am interested in developing an app that needs to utilize existing technologies to sync app specific data across multiple i-devices (iPhone, iPad, Touch, etc.). As an example, the app can be installed on multiple devices. On one device, the user will initially create an account. Then in subsequent logins, the user may create a task list, and each task item may possibly include a captured photo image. On the user's second i-device, as he logs in, he would be able to see and access the list and images (locally). Can someone explain to me what technologies I can leverage on to implement such an app?
Specifically:
How do I set up and manage the user accounts? Do I Need a dedicated server and sql database set up for my entire user base? And what programming/scripting languages do I need to learn?
How about the mechanism of pushing and pulling app data from one device to another? Do I need some kind of cloud technologies (SaaS?) to handle the storage and transferring of the data?
Any specific open source or commercial products I can leverage on?
Thanks in advance.
Kenny
I personally have not have had a situation like this, but here is what I would recommend.
You will need to have a server set up with database software.
You will need to write an api for yourself based on HTTP POST (REST) or maybe you could write a SOAP service.
I would HIGHLY recommend purchasing an SSL cert. for your server that way you can send the username and password in your request and it will be encrypted automatically.
For the api, you have a whole selection of languages and databases at your disposal. I am personally biased towards asp net with an MSSQL server.
with your api you will need to write methods to authenticate the user, and then save and send your data.
In your app you will simply send web requests to the server (ASIHttpRequest maybe?) and you can receive JSON responses back, which you can then deserialize into workable objects and vice versa.
if you do use asp net, you can use the newtonsoft JSON library to convert your objects for sending and convert received objects.
I dont remember the name, but there also is a JSON library for obj-c that is usable on iPhone.
Use a SQL server and host a database of logins and passwords.
Then, from each device, create a connection to the server, and download the login information for the account.
Also, not to be rude but: Google it.
I currently develop an iOS app for a local business directory, and I use SQLite. This sadly means I must do several hours of data entry when new businesses are added and push the updated DB out, because the desktop site uses the Joomla CMS.
Obviously companies that provide directory services don't have to worry about such things. How do they do it? Core Data accompanied by a screen scraper?
PS. I apologise if this question is inappropriate to be asked on StackOverflow, I didn't know where else to ask.
Generally these companies have a client/server architecture where the data lives on a centralised server and the mobile apps pull the data through an exposed API over the internet.
To replicate this yourself, you would have a server with all the data and expose it through an API/web service (so you'd need to think about authentication and security) which your mobile app pulls from when it needs to update the database or just have the query sent to the web service and return the appropriate results so the database does not live on the iOS device itself. The downside to the first approach (updating the DB) is you'd need to wait for the DB to fully update before the user could use the application and the downside to the second approach is to make queries, the client would need an active internet connection.
The first thing you'd want to look at is if/how you can expose the data stored in the Joomla CMS through an API (XML/JSON?)