Skip to Content

So why shouldn’t I use a Web Dynpro Project?

The project type “Web Dynpro Project” was developed before SAP had any development infrastructure software. The drawback with this type of project is that it behaves like a sealed, non-reusable container.

Nowadays, we have the NetWeaver Development Infrastructure (NWDI) to manage source versions, build dependencies and transports. This means that unless you are writing a very simple training or demo application, you should not use a project type of “Web Dynpro Project”.

OK, what should I use instead?

The answer is that you should always use Development Components (DCs) of type “Web Dynpro”. Even if you do not have a working NWDI installed, you can still create Local Development objects. In the ABAP world, this is equivalent to creating objects of package (formerly Development Class) $TMP.

The point here is that a DC is a reusable entity. If you have already created a Web Dynpro Project, then for comparison purposes, it is useful to create a DC of type Web Dynpro, and then expand the first level of the project hierarchy. You will notice that the Web Dynpro Project has three nodes directly under the project branch, but the DC of type Web Dynpro has four. The extra branch is critically important. This is the “DC Metadata” branch, and it is here that you can declare both the usage dependencies to other DCs (under “DC Definition”), and those parts of your DC that will be publicly available (under “Public Parts”).

How should DC’s be used then?

The DC of type Web Dynpro represents a reusable unit of code. This concept gives you a high level of flexibility over how your DCs should be structured, so it is not possible for me to give any exact rules about how much code should be put into one DC. However, there are some general principles to follow:

  1. A DC should be structured such that it represents a self contained unit of business processing.
  2. If a DC is made too small, then you will have highly fragmented reuse situations and end up with a complex network of inter-DC dependencies.
  3. On the other hand, if you make a DC too big, then you restrict its reusability because it will contain more functionality than is required for an individual reuse case.
  4. DCs expose their internal functionality through the concept of Public Parts (PPs). The PP is a compiled and delivered as a separate .jar file.

When you create the Web Dynpro Components within the DC, you should decide which functionality will be publicly visible, and which will remain hidden within the DC.

When you have identified a unit of functionality (for instance, a particular component) that needs to be publicly available, you should right mouse click on that entity, and select “Add to Public Part”.

If you have not created a PP before, then the first screen you will see asks you to create the PP. Give some meaningful name that describes the exposed object or functionality, and then the PP will be created and the entity added to it.

That’s pretty easy. Is that all there is to it?

N O !
Remember I said that the PPs of a DC are implemented as separate .jar files? Well, the PP jar files need to be built – this is a second, independent build process from the “Rebuild Project” option that you normally use. You must therefore select “Development Component” from the right mouse click menu on the DC node, and then select “Build” from the side-menu. Only then will the PP jar file be built.

If you forget to do a DC build, then you’ll probably be able to deploy your application (though without the PP jar files), but you’ll experience runtime dependencies failures.

So how do I reuse this functionality?

Once you have developed a DC and built its PPs, you can then declare a usage dependency from another DC. A very useful example here is to split the model objects required by a Web Dynpro application into a separate DC. In this model DC, you create only the model objects – no Web Dynpro components. Then you add each model object to its own PP (don’t forget to do a DC build each time a PP changes).

Lets say that you are now writing another DC that wishes to use one of the model objects in the model DC. So under the “DC definition” branch of “DC Metadata”, you will find the “Used DCs” branch. Here is where you can add a usage declaration to the model DC. Once you have done this, when you want to add a model usage to your Web Dynpro component, you will see all the models in the model DC when you select the “Add” option from the Used Models branch (if you don’t see any model objects when you select “Add”, its probably because you haven’t built the PPs of the model DC.

By putting the model objects into a separate DC, the model object source code only needs to be compiled once (usually a time consuming process), and then the DC that has declared a usage of the model DC only needs to reference the compiled code. This greatly speeds up development time!

To report this post you need to login first.

22 Comments

You must be Logged on to comment or reply to a post.

  1. Jochen Guertler
    Hi Chris,

    this is absolutly right – and there is some light at the end of the tunnel – in April we will release the “Praxisbuch Web Dynpro”. One of the most important topics in this books is the usage of Web Dynpro DCs to build Web Dynpro applications. All examples in this book are based on NWDI – so from my point of view this will really help customer not using Web Dynpro projects.
    The linkt to the book is http://www.sap-press.de/katalog/buecher/titel/gp/titelID-1078.

    Best regards

    Jochen

    P.S. There will be of course also a English translation of the book.

    (0) 
  2. Jochen Guertler
    Hi Chris,

    this is absolutly right – and there is some light at the end of the tunnel – in April we will release the “Praxisbuch Web Dynpro”. One of the most important topics in this books is the usage of Web Dynpro DCs to build Web Dynpro applications. All examples in this book are based on NWDI – so from my point of view this will really help customer not using Web Dynpro projects.
    The linkt to the book is http://www.sap-press.de/katalog/buecher/titel/gp/titelID-1078.

    Best regards

    Jochen

    P.S. There will be of course also a English translation of the book.

    (0) 
  3. Jochen Guertler
    Hi Chris,

    this is absolutly right – and there is some light at the end of the tunnel – in April we will release the “Praxisbuch Web Dynpro”. One of the most important topics in this books is the usage of Web Dynpro DCs to build Web Dynpro applications. All examples in this book are based on NWDI – so from my point of view this will really help customer not using Web Dynpro projects.
    The linkt to the book is http://www.sap-press.de/katalog/buecher/titel/gp/titelID-1078.

    Best regards

    Jochen

    P.S. There will be of course also a English translation of the book.

    (0) 
    1. Yasir Noman
      Hi,
         I would like ask somthing related to version of NWDS, is it posible to use DC which was made on NWDS 7.0 SP4 into the DC project which is on NWDS 2004 SP14 or any other 2004 SP?
      Regards
      Yasir Noman
      (0) 
    1. Yasir Noman
      Hi,
         I would like ask somthing related to version of NWDS, is it posible to use DC which was made on NWDS 7.0 SP4 into the DC project which is on NWDS 2004 SP14 or any other 2004 SP?
      Regards
      Yasir Noman
      (0) 
    1. Yasir Noman
      Hi,
         I would like ask somthing related to version of NWDS, is it posible to use DC which was made on NWDS 7.0 SP4 into the DC project which is on NWDS 2004 SP14 or any other 2004 SP?
      Regards
      Yasir Noman
      (0) 
  4. Yogesh Galphade
    Hi Chris

    This blog is nice and helpful.

    But I want to ask a question bit apart from this topic.

    When we do any CAF application, we use implemention of Callable Object. In such a workflow/process the first CO will start a process automatically.And then problem arises, means it will create a task in initiators UWL. And such a process stays as it is and piping in stack.

    So what is the solution for that,should we go for Start a process using GP API (But it is quite complex).

    Please Can you suggest anything on this?

    (0) 
    1. Chris Whealy Post author
      Hi Yogesh
      I’m not sure I understand your question.  But at the same time, CAF is not my area of expertise, so I don’t think I could answer it anyway.
      Regards
      Chris W
      (0) 
  5. Yogesh Galphade
    Hi Chris

    This blog is nice and helpful.

    But I want to ask a question bit apart from this topic.

    When we do any CAF application, we use implemention of Callable Object. In such a workflow/process the first CO will start a process automatically.And then problem arises, means it will create a task in initiators UWL. And such a process stays as it is and piping in stack.

    So what is the solution for that,should we go for Start a process using GP API (But it is quite complex).

    Please Can you suggest anything on this?

    (0) 
    1. Chris Whealy Post author
      Hi Yogesh
      I’m not sure I understand your question.  But at the same time, CAF is not my area of expertise, so I don’t think I could answer it anyway.
      Regards
      Chris W
      (0) 
  6. Yogesh Galphade
    Hi Chris

    This blog is nice and helpful.

    But I want to ask a question bit apart from this topic.

    When we do any CAF application, we use implemention of Callable Object. In such a workflow/process the first CO will start a process automatically.And then problem arises, means it will create a task in initiators UWL. And such a process stays as it is and piping in stack.

    So what is the solution for that,should we go for Start a process using GP API (But it is quite complex).

    Please Can you suggest anything on this?

    (0) 
    1. Chris Whealy Post author
      Hi Yogesh
      I’m not sure I understand your question.  But at the same time, CAF is not my area of expertise, so I don’t think I could answer it anyway.
      Regards
      Chris W
      (0) 

Leave a Reply