DD_DOMA_GET" not released for 'remote' calls : Advice required

[Former Member]

Hi,

This is one of the common messages that I(and many SDN'ers) received when I tried to deploy my application in WAS SP12.

I read the messages and it was quite obvious, that DD_DOMA_GET needs to be RFC enabled and this would work fine.

However, I also noticed a colleague of mine who could deploy applications without receiving this error. He has a model in his program and he tries to execute the function module as well in his Web Dynpro program and had absolutely no issues.

When I tried, I received the above error, constantly. I compared his program and mine and found a subtle difference. The view controller - context attributes were structurally bound in my case, and in his case, he used standard types as string, boolean etc... Therefore, I concluded that every time my application tries to execute, it sees a com.xx.app.type.ModelField for a view - context attribute , it uses the JCo Destination WD_RFC_METADATA_DEST and calls function module DD_DOMA_GET. It fetches the type and length of the field. In this case, DD_DOMA_GET is not RFC-enabled and therefore returns with an exception.

My question is : is this workaround i.e. to not use structure binding for context attributes of a view and use simple fields like string, boolean etc. beneficial ? What are the drawbacks of this workaround ?

Best Regards,

Subramanian V.

[Former Member · Accepted solution]

Subramanian,

First, I'm wondering how your colleague was able to create Adaptive RFC Model, while wizard uses function DD_DOMA_GET intensively to create dictionary types. Most probably, he copied it from somewhere and changed destinations.

Next, using Adaptive RFC model in described manner is almost the same as using SAP Enterprise Connector instead while any dictionary-related functionality is not used (see

, second item in list)

Valery Silaev

EPAM Systems

http://www.NetWeaverTeam.com

Message was edited by: Valery Silaev, URL fixed

[Former Member · Accepted solution]

Good point, Valery and what you assume is also right. We used a particular SAP System where DD_DOMA_GET was RFC-enabled and then changed JCo destinations.

I am not clear with your second point and in relation with my question in particular.

The two points that I made in my first and second post(I should have made them in the same post, sorry about that) are required to not get that error.

a) <b>Type</b> of View->Context->Value Attribute should not refer to model(for e.g. com.aq.model.types.xubname) , especially when there is a UI Element binding

b) Custom Controller should be bound to model and not component controller

I am not even fully sure if there are any other preconditions to avoid the DD_DOMA_GET error, but I tested with the above 2 points and my program also gets executed properly.

From your point:

<i>Next, using Adaptive RFC model in described manner is almost the same as using SAP Enterprise Connector instead while any dictionary-related functionality is not used (see

, second item in list)</i>

I understand that, if I follow points (a) and (b) as mentioned above, I am "almost" using the concept of Enterprise Connector, except for dictionary usage.

What intrigues me is why the distinction between component and custom controller(for failure - DD_DOMA_GET) and more importantly, the method that we are currently using, is it safe ?

Best Regards,

Subramanian V.

[Former Member · Accepted solution]

Subramanian,

<i>I understand that, if I follow points (a) and (b) as mentioned above, I am "almost" using the concept of Enterprise Connector, except for dictionary usage.</i>

Almost exactly. SAP Enterprise Connector (SAP-EC) has no notion of dictionary at all, So if you are using Adaptive RFC but never refer to R/3 dictionary types (via context or dynamic coding) you are in fact using semi-SAP-EC solution. However, you can still benefit from external connection configuration in SLD and WD connection pooling.

<i>What intrigues me is why the distinction between component and custom controller(for failure - DD_DOMA_GET) and more importantly, the method that we are currently using, is it safe ? </i>

That intrigues me too

From my understanding, in regard of question "all controllers are borned equals", so it should be no difference whether you are using component / custom / view controller. On other hand, using component controller assumes mapping from view controller, so probably mapping adds "gotchas".

Actually, I can not say definitely whether or not your method safe. From my experience, I cannot label it "illegal" or "forbidden". But "tricky" or "not recommended" statements could be applied

Valery Silaev

EPAM Systems

http://www.NetWeaverTeam.com

[Former Member]

Hi,

It is a good practise not to hard bind the model node to the context. Instead have value nodes with attributes of simple types and of the same name as that of the model node. This way you can just do a copy-corresponding(through WDCopyService) and load the values onto your context once the BAPI/RFC has been executed.

This has an added advantage: say if you have to re-import your model because of a BAPI structure change, you don't need to touch your context. The same code will still run.

As for your problem, I am not too sure if this approach will help if the BAPI/RFC is not remote-enabled. Is your colleague accessing the same backend R/3 as you are? Just for sanity check

Also check SAP note:717836.

Regards,

Satyajit.

Message was edited by: Satyajit Chakraborty

[Former Member]

Thank you for your quick response.

Let me clarify a few points here :

a) Our function module is RFC-enabled, but DD_DOMA_GET is not RFC-enabled.

b) We are accessing the same system.

c) My colleague has bound the model to a custom controller and not to a component controller.

d) For a given view's context's attribute, I am trying to assign the type as follows:

Barea : Type -> com.aq.test.model.types.Z_Bukrs

This is what I mean by structure binding.

Best Regards,

Subramanian V.

[Former Member]

Hi,

This is what I suggest:

1. Create your model. Do not bind it to any of the controllers.

2. In your Component Controller context, create value nodes with value attributes of simple types and having the same name as your model attributes.

3. Map these value atrributes to your view context.

4. Once you execute the BAPI, just copy the corresponding entries from the BAPI return structure to the context.

Regards,

Satyajit.

[Former Member]

If I do not do model binding, how do I retrieve information ?

Anyways, what I am more interested in knowing is :

a) Why is this workaround that I mentioned in my first post working ?

The solution should have been an open-and-shut case which means that DD_DOMA_GET should be RFC-enabled. Period.

Since this workaround is working, is it safe to use this workaround ?

Best Regards,

Subramanian V.