Transporting Portal object in NWDI - FPM configuration

[ChrisPaine]

Hello,

We have a situation where we have created our own XSS application using the new NW04s FPM. To run the application we have to point it to a configured FPM application object in the portal. (FPM application object created using Self Service Administrator Role).

Currently all portal configuration is transporting using the PCD route - not via NWDI, but all WebDynpro work is moved through NWDI.

As a developer must have the FPM objects deployed to their PC in order to run the application, and test it, we would like some way to be able to put these portal objects into the NWDI so that they can be easily brought over to the developer machines.

I found some infomation about doing something like this in:

<a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/f570c7ee-0901-0010-269b-f743aefad0db">How To… Transport EP 6.0 Content</a>

Section 5.2.2 contains details of a way to do this, but I'm pretty sure that there is a better (read - supported)way.

Indeed SAP have packaged up the standard FPM configurations into DCs which they provide with the standard ESS SC in NW04s. But their DC's don't look anything like the DC's described in the document above.

I've even created a sda from my epa containing all the portal configuration, which deploys wonderfully though the SDM (remote gui), but I am stuck on how to get this into NWDI, and it still doesn't look like the DC's that SAP created.

Does anyone know of a tool to get PCD content into a DC within NWDI. This seems like a really simple/standard thing to do, but I can't find any information about it.

Any help much appreciated.

Chris

[Former Member · Accepted solution]

Hi,

if you look at the build logs for these special "SAP-EPAs" you can see that they basically:

- convert *.xlf files to *.property files

- merge those property files into the *.ept files

- merge all *.ept files into a single *.epa file

- wrap the *.epa file into a SDA.

This is probably done so that translations for portal content can be added after the DC was created.

If you simply add the *.epa directly as documented you save yourself several steps (=time) during build.

Marc

[ChrisPaine · Accepted solution]

Thank Marc,

Although at the place I'm currently working, just adding the .epa sounds like the solution to my problems, other places I work do have the need to translate. Generally it's not the developers who do this work, so similar situation to the one which we're guessing SAP had. Then again, just for developers to make changes doesn't require all the languages to exist so perhaps not a problem.

It's a shame that no-one seems to know of a supported approach to this problem of getting portal config into NWDI. Hope that might change - well see I guess!

Cheers,

Chris

[Former Member · Accepted solution]

Hi ,

Incidentally , there is a way.. and you are really close to it.

Did u figure it out.. ? If not , please let me know..

Regards

Bharathwaj

[ChrisPaine · Accepted solution]

Hi Bharathwaj,

No - never found out how to do it, could you let me know?

Thanks,

Chris

[Former Member · Accepted solution]

Hi ,

Dont copy-paste the epa file.

Right Click on your Portal content DCs,

PCD -> Update EPA and select your .epa file . This would generate your .xlf and folders for each portal object with the GUID you were talking abt..

Regards

Bharathwaj

[SamuliKaski · Accepted solution]

Hi Chris and Bharathwaj.

I also ran into this issue. I ended up creating a CSN about it.

A kind person from SAP development replied and told that the EP build plugin was accidently placed in an older version of NWDS 7.0, that it is no longer present in the latest version. SAP kindly attached the plugin to the CSN and told furthermore that they will reintroduce support for the EP build plugin in some later version of NWDS. Until then it's unsupported. With this plugin I am able to build a DC containing the PCD objects however there is still some steps missing because I am unable to build a DC identical to the ones shipped by SAP in MSS, for example mss/eepro/genericiview/cfg.

Samuli

[Former Member]

Hi Chris

If I have understood you right . The idea here is not to import the EPA as a DC but to create a Portal Content DC and copy the EPA file into the Portal Content DC and check it into the DTR. Whats stored in the DTR is the EPA file itself and not the PCD content like iViews, Roles etc.

Apologies if my interpretation is wrong...

Regards

Pran

[ChrisPaine]

Hi Pran,

perhaps if I explain what I see when I look at DC ess/au/addr/cfg in SC SAP_ESS, this will help explain. (I've expanded the addr folder but left the other collapsed as they pretty much contain the same stuff.

ess/au/addr/cfg

+ DC MetaData

- PACKAGE-INF

package.properties

- src

- _pcd

- addr_<guid>

addr_ar.xlf

addr_da.xlf

addr_el.xlf

addr_en.xlf

addr_es.xlf

addr_fi.xlf

addr_fr.xlf

addr_he.xlf

addr_hr.xlf

addr_hu.xlf

addr_it.xlf

addr_ko.xlf

addr_no.xlf

addr_sk.xlf

addr_th.xlf

addr_zh_CN.xlf

addr_zh_HK.xlf

addr_zh_TW.xlf

addr.ept

addr.xlf

+ bizcardsview_<guid>

+ confirmationnaviview_<guid>

+ detailnaviview_<guid>

+ detailview_<guid>

+ dispatcherview_<guid>

+ fpmapplications_<guid>

+ fpmviews_<guid>

+ package_<guid>

+ per_address_au_<guid>

+ reviewcaptionview_<guid>

+ reviewnaviview_<guid>

+ reviewview_<guid>

where <guid> is a long guid. e.g. for addr it is 1f161cece3f80784b68385e8153cd22

What this looks like it contains all the portal objects required to build the FPM application for pers address au. the Folders, FPM application, FPM views used, and an additional object "package" which I guess is the epa itself. It additionally contains translation files for other languages - the xlf files. In my case I'm not so worried about not having these. All the .ept files I can find when expand out the epa that I can create from the portal, it's more all the guid's that are generated and that package.properties file, and the package folder and package .ept file that I'm not sure about.

I'm thinking that SAP had a standard way that they went about creating this DC, and I'd like to do the same for my custom XSS application. But I have no idea how to do it.

Ideas much appreciated. Let me know if you need any further info.

Cheers,

Chris

[Former Member]

Hi

Is this on NW04 or NW04s , the same project seems to look different for me(NW04) . Is it mandatory that you want to package Portal content within WebDynpro DCs?

Regards

Pran

[ChrisPaine]

Hi Pran,

This is NW04s - in NW04s it is required for ESS that FPM portal objects be deployed to the same J2EE engine that the ESS WebDynpro applications are running on. (arguably a backward step as far as infrastructure, it is a huge step forward in flexibility of the solution.)

What I want to do is package pcd information (in this case the FPM Application and views) in a DC in the same SC as my WebDynpro ESS application.

SAP managed to do this, and I'd like to too. <b>In a way that is supported by SAP</b>. SAP must have some tool/solution that they used to build the config DC's that they have in the ESS business package for NW04s. Using the new configurable FPM means that it become necessary for a solution to be able to store and easily deploy this portal config to developer machines. Since the WD code is in NWDI it makes sense for the FPM objects to be there too.

The guys in the thread seem to suggest that there is no difference between the unsupported method in the document I linked to and what SAP have done. But surely if SAP have actually built and delivered the cfg DC's for ESS in NW04, they must have had some process by which they did it.

I'm guessing that no one knows a better/supported solution for getting portal objects into NWDI, but if anyone does, please do reply!

Thanks,

Chris

[Former Member]

Chris,

I have not come across a better way to transport PCD content using NWDI than described in section 5.2.2 of the document we mention. This is the way we are doing it in the current project and that seems to work fine.

If it works, it doesn't need to look like the DCs that SAP has created...

Kind regards,

Pascal