Using SugarBeans outside of Sugar's framework

I'm not sure what you mean. The solution in the thread, as far as I can tell, is to use SugarBeans - that's what I'm bending over backward to try to accomplish. If you mean why am I trying to do it outside of Sugar itself - we are a SAAS business, so basically we use Sugar to maintain our customers, and our customers use our portal to do a number of things which we would like to make record of in Sugar. I can of course do direct SQL inserts into the Sugar tables, but I would rather leverage the infrastructure that exists within Sugar to help us maintain data integrity. For example: when I want to insert a record in a table, I would rather let Sugar generate a GUID than generate one myself.

Hi Michael Jones

Have you looked in to the CLI functionality?  If you create a CLI in "InstanceMode" then you should have access to BeanFactory and SugarBeans for that instance.

The code would be within the Sugar file system but you could execute it from anywhere as long as you have access to the <sugar_instance>/bin/sugarcrm executable.

Hope it helps.

Hi, you just need to include include/entryPoint.php file in your script and you can do whatever you want with sugar after that  Don't forget to set global $current_user - without it you would not be able to retrieve anything due to the team security (or you would have to turn it off on every retrieve...).

this is how your script should start:

<?php

define('sugarEntry', true);
require_once 'include/entryPoint.php';
global $current_user;
$current_user = BeanFactory::retrieveBean('Users',1);
_ppl("sugar magic!!");

Hi, you just need to include include/entryPoint.php file in your script and you can do whatever you want with sugar after that  Don't forget to set global $current_user - without it you would not be able to retrieve anything due to the team security (or you would have to turn it off on every retrieve...).

this is how your script should start:

<?php

define('sugarEntry', true);
require_once 'include/entryPoint.php';
global $current_user;
$current_user = BeanFactory::retrieveBean('Users',1);
_ppl("sugar magic!!");

But, aren't Entry Points deprecated and scheduled to be removed in a future release? I'd hate to depend on something that's going to disappear later. This looks like a promising approach, though!

This isn't one of the bwc entry points which were discussed above. This is basically THE file which loads sugar application, so don't worry it will become deprecated any time soon  (it is used in main index.php, api/rest.php, cron.php etc.)

No joy... it keeps redirecting me to an "install.php" file (my file was in the Sugar directories in custom/custom/ for lack of a better location):

The requested URL /custom/custom/install.php was not found on this server.

You also need to change current directory to sugar root in the beginning of the script... I thought it was obvious  ( chdir("/path/To/Sugar/Root/") ). 

Michael Jones,

There are many many ways to integrate with Sugar.

I agree with Patrick McQueen that the most robust, elegant and future proofed solution is to leverage the provided REST API. This would give you the most flexibility if/when your system will outgrow what seems to be a single server architecture shared with other systems, and still have a fully working solution just by changing the REST http url endpoint.

In addition to that, you can easily create custom REST apis that achieve complex actions and call those custom apis through REST. See here. You would leverage Sugar beans as a mean to do that, within the custom endpoint logic. 

Then as the thread progressed, you have other options like using the provided CLI framework as well.

Standalone scripts are another option but obviously those solutions make the system more tied down to the current infrastructure setup and will require a re-engineering in the future when changes occur.

Additionally, exposing framework specific functionality to the outside world via a url, might expose your company to security risks as the framework is no longer acting in its full extent, to the actions accomplished by the users. As an example of incorrect unwanted behaviour, is the possible introduction of an unwanted SQL injection problem if the script is reachable via the web and post/get variables are not sanitised accordingly and passed to the database layer directly.

Hope this helps you choose your solution of choice