Topic: REST API

Hello all

I am new to FA. I am trying to integrate FA with one of our inhouse developed systems for financial reports. Our application is in .net platform (web app). I have seen some REST APIs here.
I want to post invoices from my web application to FA. Any starting point for this?

Regards

Sume MS

Re: REST API

You can export out your invoices in CSV format and import it into FA using the Import Transactions module.

Some REST APIs are listed in the Wiki.

To use any REST API (Simple REST API) for live Invoice synch you need to locate the Direct Invoice page and identify the fields needed. Then acquire those equivalent field values for each invoice in your DOT NET and post it to the REST API or with the necessary pre-requisite credentials and hidden field values (CSRF token), you can post directly into FA. This post may be of interest.

3 (edited by s4m3shms 11/14/2017 07:45:17 am)

Re: REST API

Thanks apmuthu

I would like to follow the REST way. Is it possible for you to post a sample REST method to post an invoice.
Thanks in advance.

"Then acquire those equivalent field values for each invoice in your DOT NET and post it to the REST API or with the necessary pre-requisite credentials and hidden field values (CSRF token)" - Which API should be used for this? Is the method already available?

Regards
Sume MS

Re: REST API

hi

Also I have downloaded and extracted the zip file for REST API to modules folder.
while testing directory browsing there is no respose.

Regards
Sume MS

Re: REST API

The Slim 2.x framework with some examples are provided along with links in the hello.php file in the attachment.

Post's attachments

Slim_HelloWorld.zip 57.1 kb, 23 downloads since 2017-11-14 

You don't have the permssions to download the attachments of this post.

Re: REST API

Thank ApMuthu

How can I get parameters for a POST method? For example invoice posting.

Regards
Sume Ms

Re: REST API

Use Firebug in Firefox. Choose to submit an FA Form to a dummy POST page ( <?php echo print_r($_POST, true); ?> ) that will display the parameters and form values.

Attached is the set of SQLs that get executed for a Direct Sales Invoice being entered from the Web UI. There is a split up of the sqls into a Sales Order, a Delivery, An Invoice and a Customer Payment for the same - all of which makes for a Direct Cash Sales Invoice.

Post's attachments

FA24_DirectSalesInvoice_Anatomy.zip 78.5 kb, 28 downloads since 2017-11-14 

You don't have the permssions to download the attachments of this post.

Re: REST API

Many Thanks ApMuthu

Thanks very much, I will go through the steps and update you.

Regards

Re: REST API

One more question :

Any notes on how to install and configure Slim framework to use with this API?

Thanks

Re: REST API

All normal modules rely on the authenticated logged in session already existing within FA.

Creating a new API module will entail the creation of a session from within it as the end user will be another application server or one whose web authenticated session would not be available at the time of use.

We can however use cURL to "Log in" to FA from within the API to provide for a simulation of an authorised session while the API does it's work. Such requests will expose the credentials in plain text if the normal GET REST method is used or any other method in plain HTTP mode without suitable variable one time hashing.

@joe: Any standard construct to use the current_user::login($company, $username, $password) method in standalone mode without dependencies or listed dependencies for pre-inclusion since the $_SESSION['wa_current_user'] would not be normally available to start with?

Re: REST API

Many Thanks ApMuthu

My  API started working. The uploaded file directsales_anatomy is very interesting.
Can you confirm if you or anyone have written an API for direct sales posting?

Regards
Sume MS

Re: REST API

FA 2.3.x has a restful API developed by diaz. Search the wiki and the forum for it. Please note that the $unit_tax sent to Sales order is a proper number whilst that sent to the invoice is the result of a division by quantity yielding some irrational number in some instances.

Every transaction in FA can be deduced by comparing the backups of the database before and after the transaction and sifting the differences as I have done in the anatomy case above.

Re: REST API

Thanks ApMuthu, your comments are very much appreciated.

I totally understand your point and update my findings here.

Regards
Sume MS

Re: REST API

To get you started with Slim for FA, unzip the contents of the attachment in a folder called api under the FA modules folder, modify the URL shortcuts to suit your install and check it out. It has been hard coded for Company 1 with table prefix "1_".

Post's attachments

Slim_FA_get.zip 59 kb, 19 downloads since 2017-11-16 

You don't have the permssions to download the attachments of this post.

Re: REST API

A tutorial on Slim REST API in general is attached.

Post's attachments

Slim REST API.pdf 458.5 kb, 37 downloads since 2017-11-16 

You don't have the permssions to download the attachments of this post.

Re: REST API

@s4m3shms I've updated the Simple Rest API to support FA 2.4.x.  There's a release at this link:

https://github.com/cambell-prince/FrontAccountingSimpleAPI/releases/tag/v2.4-1.0

It includes Slim and everything it needs to work, you should be able to copy it in to a folder such as modules/api and it should just work.

I use the Chrome extension Restlet Client to test REST API's.

Cambell https://github.com/cambell-prince

Re: REST API

@cambell: please provide one that is stripped of composer and unit tests so that the end user can deploy and extend without a steep learning / confusing curve. As Slim v2.x can be used without composer by using it's internal AutoLoad feature, all vendor dependencies can be eliminated.

Your release does not work.

You have removed the class SessionManager() in the session-custom.php (not updated to reflect this core commit) but referred to it in the code at line 46.

Also you are referring to a hardcoded non-existent file/folder name in the config_api.php file: _frontaccounting

You are referring to $rootPath but have initialised $rootpath in config_api.php - in fact it is sufficient for it to have just:

define('API_ROOT', '.');
define('FA_ROOT', './../..');

irrespective of whether it is hosted on Windows or on Linux to alleviate the effect of the DIRECTORY_SEPARATOR.

You will want to add in the following into an .htaccess file:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [QSA,L]

Your api module just does not work. Tested in FA 2.4.3+, PHP 5.3.1.

Re: REST API

@apmuthu Thanks for testing this and providing your feedback.  I've made some improvements to the packaging along the lines you suggest.

apmuthu wrote:

@cambell: please provide one that is stripped of composer and unit tests so that the end user can deploy and extend without a steep learning / confusing curve. As Slim v2.x can be used without composer by using it's internal AutoLoad feature, all vendor dependencies can be eliminated.

I like using composer for development.  I'm not wanting to remove it.  However, my goal is the same as yours - that the end user can install and deploy easily.  The goal is for users to be able to download a packaged release and put it in the folder.  I agree that the packaging in my 2.4-1.0 didn't achieve that goal.

The unit tests were not present, however PHPUnit was.  I've improved the packaging to exclude development dependencies from the vendor folder.

apmuthu wrote:

Your release does not work.

Yes that was sadly true.  Thanks for taking the time to test, that's much appreciated.

apmuthu wrote:

You have removed the class SessionManager() in the session-custom.php (not updated to reflect this core commit) but referred to it in the code at line 46.

Sadly I've coded this against my version of Front Accounting which includes this pull request from January 2016 which separated out the session functions from the core session code.  This reduces the copy / paste and makes implementing both unit tests and the REST API easier.  I'll leave it to the FA community to solve that.  I can say that if you use the same version of FA that I use it will work for you.  I guess you can copy session_utils.inc into the folder and amend the pull-request.

apmuthu wrote:

Also you are referring to a hardcoded non-existent file/folder name in the config_api.php file: _frontaccounting

You are referring to $rootPath but have initialised $rootpath in config_api.php - in fact it is sufficient for it to have just:

define('API_ROOT', '.');
define('FA_ROOT', './../..');

irrespective of whether it is hosted on Windows or on Linux to alleviate the effect of the DIRECTORY_SEPARATOR.

Yes, that's needed to make the Travis CI builds work.  If you can think of another way of having Travis test a module without this technique do let me know.


apmuthu wrote:

You will want to add in the following into an .htaccess file:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [QSA,L]

I've included the .htaccess file in the packages.

apmuthu wrote:

Your api module just does not work. Tested in FA 2.4.3+, PHP 5.3.1.

Well, it doesn't work for you.  It works for me, and it works on Travis. There's the session_utils issue which can be solved by using my version, accepting the pull request from Jan 2016, or copying the session_utils file into the REST API folder.

Cambell https://github.com/cambell-prince

Re: REST API

Make the session_utils.inc file part of the API code. Will test and let you know.

Re: REST API

@apmuthu I've made a new release here:

https://github.com/cambell-prince/FrontAccountingSimpleAPI/releases/tag/v2.4-1.2

I've also updated the Travis CI tests to test against the official FA mirror on GitHub.

Cambell https://github.com/cambell-prince

Re: REST API

Here are some quaint errors:

0::Set.php:72:[before upgrade] Redefining already defined constructor for class Slim\Helper\Set

0::Log.php:304:[before upgrade] Redefining already defined constructor for class Slim\Log

Whilst the Slim framework files use the newer function __construct(), the presence of function names (even if case is different) bearing the class name will be construed as being a re-declaration of the class constructor!. See Set.php and Log.php for functions set() and log() respectively atleast in earlier versions of PHP like 5.3.1. Renaming the class file names and their class names like WSet and WLog and altering them in files they are used alleviates these errors.

Line 163 of vendor/slim/slim/Slim/Helper/Set.php should not have any return value.

Line 309 of vendor/slim/slim/Slim/Log.php simply returns the string value even if it is an passed to it. In it's earlier avatar, it was replaced by:

            if (is_array($object) || (is_object($object) && !method_exists($object, "__toString"))) {
                $message = print_r($object, true);
            } else {
                $message = (string) $object;
            }

Is line 111 of vendor/slim/slim/Slim/View.php okay?
Should Closure be preceded by a slash?

Line 18 of src/Purchases.php should be like all the others:

$body = array();

Re: REST API

Take the latest FA 2.4 API from this post. It sports the latest Slim v2.64 and does not rely on composer.

Re: REST API

@apmuthu Thanks for testing.

apmuthu wrote:

Here are some quaint errors:

0::Set.php:72:[before upgrade] Redefining already defined constructor for class Slim\Helper\Set

0::Log.php:304:[before upgrade] Redefining already defined constructor for class Slim\Log

These errors have been fixed in Slim issue 419 back in 2012 with this commit.  However, this fix was included in Slim v3.x which claims to require php >= 5.5.

Options would be to upgrade to Slim 3.x requiring php >= 5.5 or stay with Slim 2.6.x and document for those that would want to fix this issue. I'm not wanting to backport the fix simply to maintain compatibility with a very old version of php.

apmuthu wrote:

Line 163 of vendor/slim/slim/Slim/Helper/Set.php should not have any return value.

Fixed in Slim 2.6.3 which I'll use in a future release of the module.

apmuthu wrote:

Is line 111 of vendor/slim/slim/Slim/View.php okay?
Should Closure be preceded by a slash?

Fixed in Slim 2.6.3 which I'll use in a future release of the module.

apmuthu wrote:

Line 18 of src/Purchases.php should be like all the others:

$body = array();

That would be php 7 features leaking in.  I'll maintain php 5. something compatibility and make it consistent with the other modules.  Purchases is not yet feature complete.  There's no endpoint yet defined for it.

Cambell https://github.com/cambell-prince

Re: REST API

I took the easier way out by renaming the class and file to WLog and WSet instead as the original method gets used everywhere. I use Slim 2.64 and have it fully updated in my repo to manage without composer. Expect that Slim 2.x is not going to get updated very much in future, having been last updated on 2017-01-07 and FA dependant coding here will not need to rely on these low level methods at all.

All my Fixes to Slim 2.6.4 are in this commit.

Re: REST API

Thanks @apmuthu and @cambell for your great works.

I am testing the API now.

Do you have a list of added endpoints or methods for the new release?

Regards
Sume MS