QBO is capable of leveraging the QBO 2.0 Event Service in two ways:
Both of these are temporary measures pending the development of native queuing in QBO 3. Even though QBO 2.0 and 3 can reside on the same web site, they leverage different configuration files. To simplify conflict resolution, both methods use web service calls to cross application domains, ensuring that QBO 2.0 classes use QBO 2.0 configuration file, and QBO 3 classes use QBO 3 configuration files.
The QBO 3 Plugin 'qbo2.EventHandler' handled both use cases. It is available in the QBO 3 qbo.Core solution, but is not deployed by default.
QBO 2.0 can be configured to include an Event endpoint with a relative URL of /Plugins/EventService.ashx. The ProcessEvent method expects an XML document, such as:
For each Invoke element found, the Method attribute will be parsed with the following expected format:
To invoke EventService.ashx via automation, you can use any QBO Person credentials; dedicated Windows credentials are not needed. The SecurityWeb.Global.asax file recognizes when a call is being made via automation (by the absence of a User-Agent header) and will issue a Basic Authentication challenge to the calling code.
To fire QBO 2.0 events from QBO 3 code (such as Decision Processing), one must configured a Method Listener to invoke the qbo2.EventHandler plugin. Configuration should be done as follows:
QBO (2.0 and 3) use Forms Authentication to provide users with a traditional user name and password dialog to log into the site. This model is cumbersome for automation. QBO 3 enables developers to use basic authentication in their code against a QBO3 website that is using forms authentication. This replaces the QBO 2.0 pattern of having a dedicated /Service folder with Basic Authentication set up.