Back to Qbyte Gateway Home

Introduction to Qbyte 360 Connect

Safe, secure, and controlled, incoming and outgoing integration with third party applications.

Qbyte Connect is designed to allow third party integrations into Qbyte 360, minimizing the impact to risk and cost of Qbyte version (customer) upgrades. The Connectors maintain security and data integrity. They are generic and versatile to allow customer flexibility in choosing third party applications.

PLSQL Package APIs

General Standards and Concepts

• PL/SQL package consisting of a series of functions.
• As a general rule the APIs attempt to mimic the behavior of the equivalent frontend; if columns are defaulted or automatically populated by the frontend, then the API will behave in a similar manner.
• The audit columns (i.e. create_date, create_user, etc.) will not be passed in as parameters and the values of these columns will be automatically updated by the APIs.
• Functions return a Boolean variable indicating success or failure along with a return_code and return_message; the return_code is set to 0 forsuccess and -20001 for application error and the return_message will contain the error explanation.
• Complete data validations are performed by functions.
• After the first error is encountered, control is returned to the calling program.
• Most updates require all columns to be passed in.
• Default values on parameters mean that parameters are optional.
• If a parameter with a default value is not supplied on an update, the column will be set to the default value.
• APIs do not perform commits.

Security

The PL/SQL procedure will be executed with the privileges of its owner (definer’s rights). A definer’s rights procedure operates under the security domain of the user who owns the procedure, regardless of who executes it. Therefore, a user of a definer’s rights procedure requires only the privilege to execute the procedure and no privileges on underlying objects that the procedure accesses. The procedure’s owner must have all necessary object privileges for referenced objects. Fewer privileges must be granted to users of a definer’s rights procedure, resulting in increased control of database access.

How to Call the APIs

It is preferable to call the APIs using named notation. This makes the calling program easier to read, maintain, and allows it to better handle optional arguments. If there is an overloaded version of the main routine, position notation should be used.

For example: External Transactions API has number of overloaded routines with smaller number of parameters in addition to the main routine with all the parameters. The named notation call to an overloaded version of a routine could satisfy declaration of more than one routine and cause compile error – “too many declarations…”

Named Notation

Calling function with Named Notation.

Positional Notation

Calling function with Positional Notation.

The Voucher package allows for the creation of transactions:

• Journal Entries
• Accounts Payable
• Accounts Receivable
• Cash Transactions

A distinct user id should be created to use with these APIs. This user could have their password change frequency set to never, if required.  If never is not chosen, the third party will need to be updated on password changes with enough notice to make any required changes.

If the volume of transactions is expected to be high this user id should be assigned the Qbyte Connect queue. This will separate the loading of third party transactions from day-to-day processing, like voucher posting and payment processes.

A distinct Voucher Type should be created to use with these APIs. The Voucher Type must have Auto Numbering turned on.

Initial invoice creation as well as invoice adjustments are supported.

DOIs will be assigned using the standard data entry rules.

Care must be taken to ensure invoice links are created and maintained.

A pre-validation API is available and should be used to perform any possible validation prior to loading the data.

Applicable system defaults will be applied when specific data is not provided. Details of these can be found in the API documentation.

Create User, Create Date, Last Update User, and Last Update Date will be populated with the user id included with the third party call. Audit records are created for all updates.

The data is first loaded into temporary tables to ensure that all data integrity rules are followed.

The following APIs are included in the Transactions package:

• Validation API – Used for pre-validation.
• External Transactions API – Used to load and validate entries.
• Assign DOI API – Assigns appropriate DOI.
• Transaction Status API – Used to return status to third parties.