Skip to Content

NW Portal 7.4: Transporting code (.EAR files etc)??

We've just recently upgrade our portal landscape from 7.01 to 7.4 and haven't found a way to transport up code in the same manner we used to.

It used to be that our developers could create a transport in the DEV portal, and if there was code behind the iView/page etc, they could check the "resolve references" property and it would pull in the code associated with that object. Then they could transport it all in one package via CTS/solution manager etc. It worked fine.

Now it seems there's no way to "Resolve references" and pull in the associated code into a transport. The "resolve references" property is still there, but it doesn't do what it used to do (i.e. pull in the code).

So, at this point, we've been allowing them to deploy their code direct to the production portal via NWDS, which is not necessarily ideal.

Is there anyway to transport code in  the 7.4 portals short of deploying it directly to production??

Thanks for your help,

Beau

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • avatar image
    Former Member
    Jan 10, 2015 at 08:29 AM

    Hi,

    You can set up NWDI in your landscape to transport the code in quality and production systems.

    You can also perform Integration of the transports with the Change Transport System (CTS) of Application Server ABAP.

    This is the best way for the Administration of source files and transporting the code to various systems in the landscape.

    BR,

    Anurag

    Add comment
    10|10000 characters needed characters exceeded

    • We've explored NWDI in detail in the past and for the size/amount of developers and development we do on these portals, its didn't make sense to implement it. Our situation hasn't changed.

      We have around 5 developers working these portals, or less, and most the time it's less. Especially when we've been using CTS on our Solution Manager to manage the transports between the DEV and PRD portals, and it's worked great, up until this upgrade.

      So I'm hoping there's another way to do this seemingly very simple thing without implementing an entire other usage type on another system etc.