Trigger Event for PUT request method in weblogichooks

Hi Francesca,

I am not seeing fetched_row field in response of PUT notification or POST notification .

Can you provide some more information..or am i incorrect somewhere to understand it?

I found arguments.isUpdate under after_save to distinguish between PUT and POST notification response in below document 

after_save - SugarCRM Support Site

But in response i am not able to find isUpdate but able to see  dataChanges

Please provide some light on it.Thank you.

Perhaps I'm not understanding your question...

The before_save, after_save etc are logic hooks triggered by actions on the module's beans.
For example when you save a bean the relevant before and after save logic hooks you have defined will be triggered. 

https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_11.0/Architecture/Logic_Hooks/Module_Hooks/

So if you save modifications to an existing bean in your API call then the relevant logic hooks will trigger when you save those changes.

To define a Logic Hook you can follow the instructions here:

https://support.sugarcrm.com/Documentation/Sugar_Developer/Sugar_Developer_Guide_11.0/Architecture/Logic_Hooks/Module_Hooks/before_save/#Creating_a_Logic_Hook_using_Extension_Framework

I am not seeing documentation about fetched_row, though it has been extensively used for years, but maybe I'm not looking in the right place.

When you are in a logic hook the $bean is passed as a parameter to the hook method. 

If you are updating a bean then it also contains the $bean->fetched_row array which is the state of the bean before the save completes, the keys of that array are the fields that make up the bean.
Once the bean is saved that fetched_row no longer exists so you will not see it in the bean when looking at it in the after_save logic hook.

<?php

    if (!defined('sugarEntry') || !sugarEntry) die('Not A Valid Entry Point');

    class before_save_class
    {
        function before_save_method($bean, $event, $arguments)
        {
            //$bean->fetched_row exists here if this is an update
            //$bean->fetched_row does not exist here if this is a new bean
            //logic
        }
    }

?>

Francesca,

Whilst you are entirely correct in your explanation of the various places that the "trigger" events are found, I think that there might be an update you are not aware of.

I am not sure in which release it was actioned but now I believe the "fetched_row" array exists for both before_save and after_save hooks. I am certainly making use of it in recent developments (and I just tested it on a local install). As far as I can see this change was not documented, it just "appeared".

I would guess this is a response to the old issue of not having access to work out in the after_save whether it was a new record or not. Slightly moot as the recent updates also provide the flags in the $arguments parameter for this.

The "fetched_row" will also exist for a new bean (both before and after save) but the items in it will be empty if the bean is new. Which of course is functionally the same as it not existing

Thanks,

JH.

Francesca,

Whilst you are entirely correct in your explanation of the various places that the "trigger" events are found, I think that there might be an update you are not aware of.

I am not sure in which release it was actioned but now I believe the "fetched_row" array exists for both before_save and after_save hooks. I am certainly making use of it in recent developments (and I just tested it on a local install). As far as I can see this change was not documented, it just "appeared".

I would guess this is a response to the old issue of not having access to work out in the after_save whether it was a new record or not. Slightly moot as the recent updates also provide the flags in the $arguments parameter for this.

The "fetched_row" will also exist for a new bean (both before and after save) but the items in it will be empty if the bean is new. Which of course is functionally the same as it not existing

Thanks,

JH.

Thanks John. That is very good information.

I'm starting to feel "old" ;)

Hi John,

Do you feel we should improve our official documentation about this? As I read this, fetched_row belongs to $bean which is passed over to the hooks, so it has always been there and no code change for quite a while on this in our codebase..

I might be missing something here but I just want to make sure we have the proper docs up-to-date.

thanks,

Rafael,

I don't think there is any need to update the docs. As Francesca says, the fetched_row was not available for use in the after_save hook (and we are going back to versions 6, 5 or 4 here as well) but now it is.

I do not remember when it started to be available to after_save but there are a few historic forum posts (notably by Jason Eggers) regarding techniques to use fetched_row data in the after_save hook by using a static variable that specifically gets set in a before_save hook. In my recent experience that is no longer necessary. So a hole in the functionality has been plugged

Thanks,

JH.