FrontAccounting forum — Enhance DB activities to allow more extensions

Re: Enhance DB activities to allow more extensions

null@example.com (apmuthu) — Wed, 28 Feb 2018 02:08:42 +0000

You will need to pull in the data from FA into your application from within your application or program a trigger in the FA DB to populate your application DB.

To pull in FA data from within your application, use the FA SlimAPI to create a script that can be run on demand or in a cron job.

Re: Enhance DB activities to allow more extensions

null@example.com (fraserks) — Tue, 27 Feb 2018 19:35:14 +0000

Does the SlimAPI work on a push out of FA basis?

When I add or update a customer in FA, I want that details pushed to Suite. And in Suite, I have a module that will push to the other integration points when it updates records.

Thanks

Re: Enhance DB activities to allow more extensions

null@example.com (apmuthu) — Tue, 27 Feb 2018 19:07:51 +0000

Connecting to other applications is best done using the REST API (See SlimAPI in the wiki).

Enhance DB activities to allow more extensions

null@example.com (fraserks) — Tue, 27 Feb 2018 16:59:52 +0000

Greetings all,

I am working on an extension to send customer data from Front Accounting to our newly implemented SuiteCRM instance (and eventually our WooCommerce shop). I see in the Sales area, there are hook_prewrite and _postwrite calls passing the shopping cart, which would let me send sales data.

I would like to suggest we enhance the other areas of FA similarly. To this end, I've started in the customer area. I have defined some new types CT_ADDCUST etc. I have also added the pre and post hook calls in the 6 routines that add/update/delete customers and branches.

define('CT_ADDCUST', 50 );
define('CT_UPDATECUST', 51 );
define('CT_DELETECUST', 52 );
define('CT_ADDBRANCH', 55 );
define('CT_UPDATEBRANCH', 56 );
define('CT_DELETEBRANCH', 57 );

To allow this to be upgrade safe and the extension module not needing to know the triggering core module, the types defined in includes/types.inc would need to be renumbered so that each transaction type is unique (they currently restart at 1). (e.g. BT_TRANSFER 1)

Ideally, all of the core modules would pass an object, similar to the CART in the sales area, but an interim step that I have working would be to use func_get_args() to pass an array:

$arr = func_get_args();
hook_db_prewrite( $arr, CT_ADDBRANCH );
db_query(...);
//if there is a returned index value (i.e. on insert) we could add that into the $arr...
hook_db_postwrite( $arr, CT_ADDBRANCH );

I am currently developing against 2.3.22 but also did a quick check in 2.4.1 to see if there had been any changes along this lines in the customer/branch codes.

As I have only started working this, I am very open to ideas on how to architect this, and if anyone can identify reasons for FA to NOT have these enhancements.

Have a great day!