JDI and EP

[Former Member]

Hi Friends,

I have a couple of questions regarding JDI. Hope you can help me...

1. How can JDI be used with EP?

EP content is mostly .EPA or .PAR content. This can be transported easily with System Administration -->Transport --> Export/Import. why should we use JDI here?

2. In real time scenarios, what content is usually transported using JDI, i.e. .EPA or .PAR or both.

3. Let us say, that JDI would be useful for transporting .PAR content, but this can be transported when transporting .epa files using import/export. so why should we use JDI to transport PAR FILES?

I am mainly focussing on EP. ofcourse it plays an important role when developing SAP java applications.

I hope that someone can help me in this regard.

Thank you

[Former Member · Accepted solution]

hi,

1) I haven't heard of NWDI being used for PortalContent (EPA) - I don't see any advantage of this or how to get PortalContent into DeveloperStudio for CheckIn into NWDI.

2) NWDI (JDI) is good for central source / transport management of JavaApplications - preferrably in team-development. These can also be PortalApplications (JSP-Dynpage,..). Somehow I couldn't figure out how to deploy PAR's from NWDI automatically.

3) How do you transport PAR-files with EPA-content? I always upload the PAR-files through AdministrationConsole in EP Support->PortalRuntime.

[Former Member · Accepted solution]

Hi Schanffer,

Thank you for the reply.

1. You can create a DC for each EPA file and checkin into DTR, transport etc... but me too didnt find any advantage with this approach.

2 and 3. In the DEV system, we upload the PAR from System Administration --> support console and create an iview out of that.

Now if you want to transport this .PAR and iview to QA, what you can do is to create an .epa file and add the iview that is created, which also includes .par file by default.

so we can transport the .par file using this approach. so what is the necessity of JDI in this context.

Please correct me if I am wrong

thank you

[Former Member · Accepted solution]

With the use of JDI you can synchronize the transport of your EPA and PAR files. That's the big advantage. No more non-functioning iViews, because you forgot to upload the PAR file.

[Former Member · Accepted solution]

but the EPA files by default contain the .par files , so there is no chance of forming non-functioning iviews..

and we can use Sys administrtation --> import/export

Finally, I could think of one advantage, i.e. seperation of code from content. if i change a particular par file, i need not again create an epa and import /export to qa. instead of that I can transport directly from my NWDS to QA via JDI.

so in this case the iview is not transported again.

please correct me if i am wrong.

[Former Member · Accepted solution]

You are correct

[Former Member · Accepted solution]

Hi Reddy

Well the JDI would help you

->achieve a source repository and version control for all your java components.

->The build management and propogation of code into different landscape servers , which otherwise you would have to do with an "clean room" NDS.

->With complex scenarios like managing change requests and bug fixes on a single code base , you cant manage it with just pure NDS. You will have to use advanced features of CMS such as Track connections , and conflict

resolution mechanism within the DTR

Regards

Pran

[Former Member · Accepted solution]

> 2) NWDI (JDI) is good for central source / transport

> management of JavaApplications - preferrably in

> team-development. These can also be

> PortalApplications (JSP-Dynpage,..). Somehow I

> couldn't figure out how to deploy PAR's from NWDI

> automatically.

I have the same problem.

I looked in the SCA created in the "Assebly" step before importing to test in CMS.

It contains two folders "BUILDARCHIVES" and "DEPLOYARCHIVES".

I would guess that buildarchives would contain the API-publicpart files from the DC's and DEPLOYARCHIVES contains the Assembly-publicpart files.

In order to get something deployed the DC should contain a deployable part. EP-library projects don't have a deployable part for instance. In that case you would wrap them in a EJB and a EA.

However, I find my Dynpages in the BUILDARCHIVES and not in the DEPLOYARCHIVES. I don't know if I'm supposed to pack my dynpages in an EA to get them deployed...

The file META-INF/CBS_INFO.PROP (inside the sca file) contans the following about the dynpage.

<dc-name>.broken: false

<dc-name>.buildarchive: exported

<dc-name>.buildlogurl: http://xxxxx/tc.CBS.Appl/servlet/archiveapi.

<dc-name>.cbsbuildlogurl: http://xxxx/tc.CBS.Appl/servlet/archiveapi.

<dc-name>.deployable: false

<dc-name>.dirty: false

<dc-name>.variantbuildnumber: 14462

<dc-name>.variantname: default

I'd like to change the .deployable parameter to true...

Havn't found anything on sdn about this.

Any hints?

/Mikael

[Former Member · Accepted solution]

NWDI/JDI can only deploy SDAs through SDM. A *.par file is not a valid SDA.

The NWDS offers two DC types: "Portal Application Module" and "Portal Application Standalone". If you use the "Module" type you can assemble the modules into a J2EE/Enterprise Application DC (create DC dependencies to the "PAR" public parts). If you use the "Standalone" type the DC build will directly produce an SDA and if you assemble those components into an SCA you will also see the deployarchive.

(For a low-level migration: check-out the .dcdef file and modify the DC type in the XML file and remove the public part if you switch to Standalone.)

Regards,

Marc