Check /people/chris.whealy/blog/2006/01/13/when-creating-a-java-web-dynpro-application-dont-use-the-project-type-quotweb-dynpro-projectquot from Chris Whealy.
I was able to implement the second option, could you please elaborate the first option (The java import)?
And two more questions while we are on that subject:
1. If I developed a Local DC and deployed it, without using the CBS, will another developer be able to use my Public Parts and use them at his projects or each one can use his own declared public parts?
2. When I create local DC it is not being created under the workspace as local Dynpro projects. Why is that and is there anyway to change it to be created at the workspace as well?
1) In case you are using local DC it is still local even if you deploy it on server. DC is more for design time than for runtime. So you need to distribute it among the team members. And they need to import your local DC to their development enviroment and afterwards can use within their local DC`s.
2) Goto Window-preferences-Java development infrastructre-development configuration pool. there is a property "Root folder". This is the folder where your development configurations are located. So, by default you have "Local Development". Open perspective "Development configuration perspective" and view Local DC`s. Select "Local Development" and in Properties view you will see Root Folder of this development configuration.
Could you please explain me though how do I distribute my Public Part? I assume it has a certain JAR file the other memebes need to have but which one is it, where do I find it and how they are actually use it? Since it's my first time using DCs a step-by-step explanation could help a lot...:)
You might want to look at <a href="http://help.sap.com/saphelp_nw2004s/helpdata/en/62/06108b6af0264a9a5393fd787ea3c9/frameset.htm">this</a> on the SAP help site.
This link and it's sub-links describe how to create and expose a Public Part in a DC. That I already know, what I don't know is (suppose we are working only locally) is to take this Public Part from my PC, put it in another Developer's PC which will import it and use it for his development. Suppose this PP is deployed, he than will be able to to deploy his project and use the PP on runtime, just like consuming a portal service: Importing it's interfaces for local work, declaring a reference to it and using it on runtime. What I would like to know is
the exact procedure of how to do that:
1. How do I recognize the PP on my PC ?
2. Where do I put it at the other Developr's PC ?
3. How the other developer import it?
4. How the other developer declare it's usage at runtime?
You will need to know the following points to understand how to transport PPs (Public Parts) from DCs in
one system to the DCs in the other (without using JDI.)
1.) Once you have declared a WD component as a public part and built the corresponding DC, navigate to <i>C:\Documents and Settings\<UserID>\.dtc\LocalDevelopment\DCs\<Vendor>\<DCName>\_comp\def</i>
to find the corresponding generated public part file (componentName.pp).
2.) Before we discuss about transporting the pp to another system, let us assume that the other developers also have the same DC (with the same name) available in their systems.
Now, copy this .pp file from your system and paste it to the aforementioned folder structure in your colleage`s system.
3.) Reload (Reload + Rebuild) the project that corresponds to the DC in picture.
4.) Then, close and open the project.
5.) Build the DC.
That`s it. Public part would have got generated. You may see the generated public part by navigating to the folder structure mentioned below:
<i>C:\Documents and Settings\<UserID>\.dtc\LocalDevelopment\DCs\
The important point that you should note here is that the metadata required for the generation of public part gets stored in the (componentName.pp) file when you declare a public part. The corresponding jar file is generated once you build the DC.
One question though: You assumed that the other developers also have the same DC (with the same name) available in their systems, but what if they would like to use this .pp file from a different component, not necessarily by the same name? After all, this is the whole point of the pp's... Will they need to create one by the same name at their System just so they will be able to consume it from other DCs...?
One question though: You assumed that the other developers also have the same DC (with the same name) available in their systems, but what if they would like to use this .pp file from a different component, not necessarily by the same name? After all, this is the whole point of the pp's... Will they need to create one by the same name at their System just so they will be able to consume it from other DCs...?
One question though: You assumed that the other developers also have the same DC (with the same name) available in their systems, but what if they would like to use this .pp file from a different component, not necessarily by the same name? After all, this is the whole point of the pp's... Will they need to create one by the same name at their System just so they will be able to consume it from other DCs...?
One question though: You assumed that the other developers also have the same DC (with the same name) available in their systems, but what if they would like to use this .pp file from a different component, not necessarily by the same name? After all, this is the whole point of the pp's... Will they need to create one by the same name at their System just so they will be able to consume it from other DCs...?
One question though: You assumed that the other developers also have the same DC (with the same name) available in their systems, but what if they would like to use this .pp file from a different component, not necessarily by the same name? After all, this is the whole point of the pp's... Will they need to create one by the same name at their System just so they will be able to consume it from other DCs...?
One question though: You assumed that the other developers also have the same DC (with the same name) available in their systems. Is this a must? Meaning, They must create a DC by the same name at their system in order to consume it's pp or can I drop this pp file at any component at their system at the def folder, Reload it and they will be able to see it...?
One question though: You assumed that the other developers also have the same DC (with the same name) available in their systems. Is this a must? Meaning, They must create a DC by the same name at their system in order to consume it's pp or can I drop this pp file at any component at their system at the def folder, Reload it and they will be able to see it...?
One question though: You assumed that the other developers also have the same DC (with the same name) available in their systems. Is this a must? Meaning, They must create a DC by the same name at their system in order to consume it's pp or can I drop this pp file at any component at their system at the def folder, Reload it and they will be able to see it...?
One question though: You assumed that the other developers also have the same DC (with the same name) available in their systems. Is this a must? Meaning, They must create a DC by the same name at their system in order to consume it's pp or can I drop this pp file at any component at their system at the def folder, Reload it and they will be able to see it...?
It is NOT mandatory that the name of the target DC (in the other developer's system) should be the same as the name of the source DC. However, I really donot see any point in having a .pp file in some anonymous DC which doenot contain the WD component in picture, for which the pp is generated.(at the source DC.)
I guess you are taking about used components and not pp declaration, am I right?
I think I wasn't clear enough, allow me to rephrase my question: Suppose I would like another developer would use a pp I've created. Does he need to create a DC (Any DC) and put my pp at it's config folder or can he do it without creating any DC by simply drop this pp file in a certain directory of the DC which would like to use this pp? The reason I am asking it is because I would likee to know if there is any way to avoid creating a DC on the other developer machine each time I would like him to use a pp from one of my DCs...
To expose the component as a java code follow these steps.
1. Go to the WebDynpro Explorer view.
2. To add a public part, open your DC node.
3. Open the DC MetaData node.
4. Select the node Public Parts.
5. From the context menu, choose New Public Part...
The dialog window Add Public Part appears.
6. In the New Public Part dialog enter the name of the new public part,say pp1.
7. Select the radio button Provides an API for developing/compiling other DCs.
This creates a public part other components can compile against. For more information on the purposes of public parts, see Structure <a href="http://help.sap.com/saphelp_erp2005/helpdata/en/80/096744c271f8408bae38a49d556c80/content.htm">Purposes of Public Parts</a> .
8. Enter some caption.
9. To confirm your changes, choose Finish.
<b>Addition of Public Part Entities to Public Part api</b>
1. Open the Public Parts node in WebDynpro Explorer view.
You see a new entry named pp1.
2. Select pp1 -> Entities and choose Edit Entities… from the context menu.
A dialog window Input Help: Entities appears.
3. Select Java Package Tree in the Select Entity Type tree and mark the checkboxes for the required folders to be exposed.
4. In the section Add Entity to Public Part, select the entry as Class and confirm with Finish.
After this, build the DC and you will get the corresponding jar files in the folder structure I've mentioned previously in the thread. Then, you may use these jar files in the target application, just like any other external libraries.
Note: I have not tried it in my system. So, I am not sure if it will work or not. Just give it a try.
I made this procedure and I am able to import the first component. The only question left is how do I receive an instance of the PP in order to use it's methods?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.