I am attempting to integrate a web site with Quickbooks Pro 2012 and would like to know what the recommended method is as I'm having a hard time getting information from the Intuit site.
Can I use QBFC13 with Quickbooks 2012 or do I have to use QBFC12?
Since this is a website, I think the correct method is to use Web Connector, although the web server could have direct access to the QuickBooks company file.
I'm been looking for a recent Web Connector sample (one that doesn't use Microsoft.Jet.OLEDB)
1. Can I use QBFC13 with Quickbooks 2012 or do I have to use QBFC12?
To my knowledge, all newer version of the SDK should work fine on older version of Quickbooks. I believe I read somewhere that they make an effort to keep it backwards compatible.
2. Since this is a website, I think the correct method is to use Web Connector, although the web server could have direct access to the QuickBooks company file.
I personally did not go with the webconnector route, because I needed real time comms. The webconnector will periodically "connect" to your website, and ask if it has any work for it to do. I personally created my own WCF Self Hosted service, which the website conencts to when needed. This wcf service, then interfaces with the quickbooks SDK, and passes the required info back to my website, when it wants it.
3. I'm been looking for a recent Web Connector sample (one that doesn't
use Microsoft.Jet.OLEDB)
Cant help you out here, although the QB specific stuff should generally still apply? Can't see why an example using a Jet DB would make the QB part of it unclear?
You can use either. You just need to make sure the QBXML version used is supported by QB.
Yes, you will need to use the web connector since this is going to a web site.
Related
We must use C# MS bot in windows service. How to implement it in .Net core for MSBot SDKv4?
All samples using IIS/Azure App service as hosting platform.
They're aren't any examples or samples that show how to explicitly do this. But you should be able to follow articles such as this or this and then tweak as needed. It shouldn't be much different than hosting any other asp.net core application.
The two points to make sure and cover are:
Make sure that the bot/application is configured (whether in appsettings.json or otherwise) so that it has the right configuration data. Specifically appid/password
Ensure the endpoint can be hit by the connector/channels.
Since CodenameOne doesn't support "the cloud storage API" any more and the parse.com is going to retire soon as well. Does CodenameOne has any plan to release a new Cloud Storage API or provide suggestions/guidelines to help developers to deal with the parse4cn1 library code, cloud code, database structure and data in parse.com?
That is something you will have to figure out yourself as parse4cn1 was initially contributed by a community member and wasn't developed by Codenameone team.
You can use a simple webservices created in php, python or java, hosted along your content with any ISP.
You may also have a look at amazon aws which is promising, they provide a cloud solution but their SDKs is not yet integrated to Codenameone.
I made the parse4cn1 lib and I'm also wondering what's smartest to do. With the announcement of Parse.com's imminent shutdown, there's been a lot of discussion around alternatives. My feeling is that "the dust is yet to settle" as per what options are best and reliable for the longer term (it would be a pity to migrate to another service only for it to be shut down soon). So I personally plan to wait till sometime in Q2 to do a proper evaluation of the alternatives. Hopefully, there'll be more clarity then.
The option to host one's own Parse server (e.g. on AWS or Heroku) is getting interesting. They recently announced support for push notifications on iOS and Android. If (when?) they open source the Parse.com dashboard code, I think that option would be much more interesting.
At some point in the coming months, I plan to make a parse4cn1 release that exposes an option to set the server path. With that, anyone migrating to the Parse server option should, in principle, be able to continue to use the cn1lib. Of course, for features that are supported by the open source Parse server.
PS: Here are pointers to some of such discussions on Parse alternatives:
https://github.com/relatedcode/ParseAlternatives
http://www.slant.co/topics/5219/compare/~firebase_vs_kumulos_vs_kinvey
I'm using Parse.com SDK services for my Android app.
I've seen that Parse had released their Android SDK as an open source project on Github on this address.
My app is almost finished, and when I'm uploading it to the Play Store, I don't want to be controlled by Parse.com (I mean that I don't want to be blocked someday, or I don't know that), so I want to move my whole database to my own server that hosted on a secure company.
I've checked the open source project on Github and realized that all I need to use it on my own server is to generate an Application ID and a client key.
So I want to ask if someone knows how to generate an Application ID and a client key of Parse to use it on my own server, or that you maybe knows another way of moving it to my server? And one more question: Today I'm using also Facebook SDK with my app. If I will move my database to my own server, will I still be able to use Facebook SDK on my app?
Thanks!
I have write an article about how to migrate parse to a custom server.
https://medium.com/#jcminarro/run-parse-server-on-your-own-server-using-digitalocean-b2a7d66e1205
There's a massive difference between Parse open-sourcing their SDKs compared to revealing their entire backend architecture and its configuration.
The open-sourced SDKs are essentially wrappers for Parse's REST API along with some convenience functions and logic for natively interpreting the JSON data Parse is transmitting.
At a high level, Parse uses MongoDB for its core database and is entirely hosted using AWS (Amazon Web Services). The entire architecture is highly complex and is not something you could just drag and drop onto your own software stack or hardware backend.
To help give you a better idea of how Parse achieves all of their services, here's an interesting presentation their Dev Ops team gave at an AWS convention. Suffice it to say, hosting the backend services for over 180,000 apps requires a complex infrastructure and that is the "secret sauce" so to speak for Parse and is why Facebook purchased them for over $85 million two years ago.
I put together some code for accessing CRM using the DLL's provided in the SDK download and tried out both the early binding approach and late binding approach.
What I'd like to do is in addition to having some custom entities that my users will access in Dynamics (through the Dynamics UI in the cloud), I also want to build some Android apps that talk to Dynamics.
My understanding is that I can talk to Dynamics from Android via REST (assuming I properly handle the authentication and getting tokens using ADAL libraries since my Dynamics instances run on the Microsoft cloud) or I can use the SDK with .NET as a middle-tier.
What's the recommended approach? Is there a best practice? When would I use the DLL's provided in the SDK and maybe wrap them in my own Web API vs. connecting to Dynamics directly via REST?
Please help this noob.
Kind of hard to say, depends on your talents and needs. Here is a great website link to get started though:
http://blogs.msdn.com/b/crminthefield/archive/2015/01/12/build-your-own-crm-mobile-app-s.aspx
Just a note on the Rest calls, you can only perform CRUD operations by default, and will need to jump through some hoops to perform the other calls.
I currently developing a multi tenant saas application using asp web api. The api will be published and consumed by 3rd party application. My question is regarding versioning. I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api. I also have to update the old api to adapt to database change. That seems like a lot of work. How do big companies solve this problem?
There is no easy way around this; you will have to do the work to support old versions as long as your customers are using them.
Adopting a RESTful approach in the first place, and avoiding 'fat controllers' may help reduce the pain but beyond that every old API call will need to call into your new service layer and will need to return the results in the format your clients expect.
I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api.
No one, absolutely no one has researched, built, versioned and maintained APIs more than NetFlix - not externally but internally. They used explicit versioning (e.g. URL) in their APIs and maintained multiple versions of the same API and got their clients move along by providing incentives (new features). This is also something that can be built into your SLA, e.g. you guarantee support of particular version only for 12 months.
This is a very controversial topic and you will hear people suggesting implicit versioning (e.g. by media type etc). Feel free to listen to those but pragmatism favours explicit and purism favours implicit.