OVS Controller

[former_member132268]

Hi,

Did anyone try out the OVS Controller?

I am running into issue while using OVS controller for showing value help for an input field “Product ID”. I am using adaptive RFC call to get the data. I have used the helper context to build my OVS Controller. I have used BAPI output structure to bind to the OVS Output query node. This BAPI output structure has a field for storing GUID of type binary. The system is unable to bind the data and show on the pop-in window due to this GUID field (exception thrown at runtime - java.lang.IllegalArgumentException). I am not sure the reason - anything to do with the binary field?

Another related question is there are anyway of hiding this GUID field from the user within in the OVS pop-in window? I cannot do away with this field as it is required for processing within my application.

I tried to delete this field from the model context node but the system still shows this field as it uses the model context binding structure instead of individual model attributes declared within the OVS Query Output node.

Any input will be greatly appreciated

Thanks and regards,

Hematnh

[BeGanz]

Hallo Garg,

As soon as the given RFC has not the correct structure, which means that the defined context structure (model node with inner nodes and attributes etc.) is not "OVS-able" , you have to define your own helper context. Instead of using the model-nodes directly as OVS-Input and-Output-nodes you have to define some additional value node(s). Based on these value nodes you then have to copy the node element data to and from value-node to model-node.

Such a scenario is implemented in the attached sample application based on Bapi_Flight_Getlist.

In addition read the following article about the OVS valuehelp in SDN: https://www.sdn.sap.com/sdn/developerareas/webdynpro.sdn?page=TutWD9_OVS.htm.

The article contains this paragraph dealing with your problem:

<i>In some application scenarios the backend does not provide an OVS-adapted RFC-function. OVS-adapted means that all required input attributes are on the same level in one input structure (OVS input node after model binding). Likewise all attributes to be displayed in the search result table have to belong to one output structure (OVS output node after model binding). So the OVS does not support input or output attributes on different levels. The solution for this restriction is to declare separate OVS input or output nodes. These nodes are value nodes with all required attributes, properly typed with Simple Types of the Logical Adaptive RFC Dictionary. Copying data between the used model nodes and the additional OVS input and/or output value nodes has to be implemented in the OVS listener</i>.

Concering the GUID attribute of type binary in the OVS input node: it seems that the generic table creation logic does not handle attributes of type binary correctly. I will communicate this issue to the Web Dynpro Java runtime development team.

Regards, Bertram

[Former Member]

Hi Hemanth

I am not sure about your first problem. But for your second issue.

Try creating a wrapper remote func module and place the GUID in a structure and make it part of your table parameter. This way it is removed from the input fields as so does not come on to the screen .But you can anyways map data to this field through code.

Regards

Pran