It's much more fun, when you can discuss your problems with others...
You are not logged in. Please login or register.
FrontAccounting forum → Modules Add-on's → 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
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.
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
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
The Slim 2.x framework with some examples are provided along with links in the hello.php file in the attachment.
Thank ApMuthu
How can I get parameters for a POST method? For example invoice posting.
Regards
Sume Ms
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.
Many Thanks ApMuthu
Thanks very much, I will go through the steps and update you.
Regards
One more question :
Any notes on how to install and configure Slim framework to use with this API?
Thanks
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?
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
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.
Thanks ApMuthu, your comments are very much appreciated.
I totally understand your point and update my findings here.
Regards
Sume MS
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_".
A tutorial on Slim REST API in general is attached.
@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: 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.
@apmuthu Thanks for testing this and providing your feedback. I've made some improvements to the packaging along the lines you suggest.
@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.
Your release does not work.
Yes that was sadly true. Thanks for taking the time to test, that's much appreciated.
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.
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.
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.
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.
Make the session_utils.inc file part of the API code. Will test and let you know.
@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.
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\LogWhilst 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();Take the latest FA 2.4 API from this post. It sports the latest Slim v2.64 and does not rely on composer.
@apmuthu Thanks for testing.
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.
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.
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.
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.
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.
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
FrontAccounting forum → Modules Add-on's → REST API
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 4 official extensions. Copyright © 2003–2009 PunBB.