Download of Attachment with Action - Confused...

[MattHarding]

Hi All,

I'm building custom Gateway objects for EH&S Incident related BOPF and am trying to figure out how to trigger the action to download an attachment and get the contents of the file to stream back.  While I can test this in the test tool and see the content being returned from the Action in the Attachment BO, I'm unclear how to get a hold of this content when using the service manager API's.

Current non-working code looks like this:

data(o_attachment_node) = o_root_node->get_subnode_by_key( if_ehhss_inc_c=>sc_association-root-att_document ).
      if o_attachment_node->has_more_rows( ) = abap_true.
        o_attachment ?= o_attachment_node->get_next_row( ).
        append INITIAL LINE TO it_key ASSIGNING FIELD-SYMBOL(<s_key>).
        <s_key>-key = o_attachment->key.
        o_service_mngr->execute_action(
          exporting
            iv_act_key       = if_ehhss_inc_c=>sc_action-att_document-download_document     " Action
            it_key           = it_key    " Key Table
        ).
        o_attachment ?= o_attachment_node->get_row( 1 ). “ Attempting to refresh the data but this doesn’t help.
        s_stream-value = o_attachment->content. “ Content is still empty after action, though in action debug, it is definitely retrieved.

Can anyone:

a) Tell me how to get a hold of this precious content? and

b) If possible, explain the relationship of the action to the reading of the node (get_row) - if any, and how you would even know what the result is from this action since in the configuration for this action, it just shows the class which handles the functionality without any export parameters. e.g. How do you know how to get the result of o_attachment from the execute_action based on the definition.

Thanks,

Matt

[BenPatterson]

Hi Matt,

A) try:

    o_service_mngr->execute_action(
       EXPORTING
         iv_act_key       = if_ehhss_inc_c=>sc_action-att_document-download_document     " Action
         it_key           = it_key    " Key Table
     ).
     o_attachment_node->flush_collected( ). "<== Add to force refresh of ENA node
     o_attachment ?= o_attachment_node->get_row( 1 ).

I tested and it worked for me. Please confirm if it works for you.

This is more of a trick with the EHSM Foundation 'Easy' Node Access (ENA) framework itself, rather than the BOPF. Because the values are retrieved from the BOPF runtime from the first get row call, and they are buffered and re-used even on the second one. The flush gets it to go back and refresh from the BOPF  (which are buffered anyway: I find the ENA framework provides some nice syntactic sugar but manages too much state)

B) You are right, actions do not have returning parameters, they are in essence an implementation of the command pattern, so I guess the trade-off is the flexibility of configuration/definition of the actions for potentially reduced clarity in the self-descriptiveness of the API.

So to answer your question, an action will have an effect on the state of the object. Sometimes you (or the client) doesn't care what that is exactly. But in this case you do need to know what the change is in order to react to it. Because of this actions should be as simple and self describing as possible (so, even though the function is simple, maybe it should have been called "retrieve_content" in order to be more explicit regarding the outcome) but of course, the only way to know for sure, is to look at the code

Hope it helps,

Ben.

[MattHarding]

Thanks yet again Ben. That indeed was the fix I was after (and will add flush_collected to my list of read-only methods that may help - I usually reserve thinking that Flush is a write-only method but hey, whatever works).

And debugging this doesn't really help in this scenario since:

a) You can see the download working perfectly;

b) All the framework code around it that still doesn't imply you need to do flush_collected).

I think debugging is actually the number 1 reason I don't like BOPF since unless you understand _all_ aspects like this; you are completely lost at what you should do and it takes so much framework code to delve into the underlying implementation code (obviously you can jump straight into the class code but you don't get to see the whole picture and that implies you start debugging by first going to transaction BOBF)!

But then again, maybe my dislike only refers to the ENA aspects???

Cheers,

Matt