Unsure how to handle eo_message in signature of /BOBF/IF_FRW_ACTION~EXECUTE

[juergen_ette]

Hi community,

I am not happy with the exporting parameter eo_message of the interface method /BOBF/IF_FRW_ACTION~EXECUTE .

It would have been nice if the framework would instantiate this and I need not to think about instantiation.

My question is if it is ok to instantiate it once in the constructor of the class implementing /BOBF/IF_FRW_ACTION for the corresponding BOBF action and to assign this instance to a class member which can be consumed if needed.

My doubt is whether this method is called multiple times resulting in adding errors of former call added to the BOBF log.

But I do not want to add in the error handling code the instantiation again and again.

Please advice.

Regards, Jürgen

Message was edited by: Juergen Ette At the moment I do it this way:   METHOD constructor.     me->bobf_frw_message = /bobf/cl_frw_factory=>get_message( ).   ENDMETHOD.   METHOD /bobf/if_frw_action~execute.    eo_message = me->bobf_frw_message. ....   ENDMETHOD. For AUnit I could drive out this productive instantiation by a local /bobf/if_frw_message implementation.  

[former_member190794]

Hello Jürgen,

as BOPF is reusing instances of the classes of actions/determinations/Validations, you have the issue that older messages might be still contained in your local message object (as you mentioned).

We thought about this point in the past and I personally also would prefer some bound IO_MESSAGE importing reference variable. However, today it is an exporting parameter and a change of that interface removing that EO_MESSAGE would be not compatible.

Best regards

Tilmann

[juergen_ette]

Hi Tilmann,

thank you for your reply.

Indeed to change this behaviour you would have to set this parameter as deprecated or - may be better - a new method needs to be offered.

My question is now what would be best practice?

Hopefully the BOBF framework can handle instances of this interface with no messages.

My idea would be to write a factory offering a method for instantiation. This factory may be exchanged for AUnit.

Any better ideas?

Regards, Jürgen

[former_member182889]

Hi Jürgen,

In our project, we provide a (stateless) helper class for moving message objects into the eo_message container. This helper is also a good place for e. g. adding message objects to the container on basis of a BAPIRET2-table.

Whether you are using a static class or an instance created from a factory is up to your personal architectural liking. Imho, the testable unit is the action-execution, so I don't see a need to mock this container (in contrast to if it were a handler imported into the method as we'd all like it to be ).

Cheers,

Oliver

[Former Member]

I feel its fairly useful. As we don't have to bother about how the BOPF framework will use the message to display info on UI. I feel its pretty neat approach. Would love to know if there are any specific disadvantages of this Export variable/approach ?