Skip to Content
avatar image
Former Member

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

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.

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • Best Answer
    avatar image
    Former Member
    May 18, 2006 at 07:32 AM

    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

    poll-sap-enterprise-connector , second item in list)

    Valery Silaev

    EPAM Systems

    http://www.NetWeaverTeam.com

    Message was edited by: Valery Silaev, URL fixed

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      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

  • avatar image
    Former Member
    May 18, 2006 at 04:47 AM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member 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.