Questions & Answers

[king]

Dear e-Spirit team,

when there might be a use case, where the SAP Netweaver Portal environment is split up into:

- KM instances

- and non-KM instances

the "HLP-BP Navigation for FirstSpirit" might be deployed on both environments. Then, it might be helpful to separate the XML registration process:

- navigation XMLs go for non-KM instances

- search XMLs go for KM instances

Up to now, the "ActivatePortalXML" task within a FirstSpirit deployment run does call the HLP-BP webservice client, that registers the XML files. The enclosed screenshots do show these configurations currently:

The implementation creates a new native process on the operating system for calling the HLP-BP content creator client. The path for the client is being configured within the corresponding module configuration setup. The following setting is important "urlPrefixActivationClient" (display name: "Path to activation web-service client")

The problem:

- the configured bash script contains the Portal-URL where the XMLs will be registered

A possible solution:

- create a 2nd "ActivatPortalXML" action entry

- just enter FirstSpirit IDs of "portalEntryPoints" (see 1st screenshot) of type "search"

- remove "portalEntryPoints" of type "search" in the 1st "ActivatePortalXML" action configuration

- overwrite the value already available within the scheduler script context (object "context") named "urlPrefixActivationClient" in the 2nd action before method "execute()" of class "de.espirit.firstspirit.opt.portal.script.ActivatePortalXML" (reason: a second entry for "Path to activation web-service client" is not available in the Portal configuration dialog) is called.

Our question:

- is this solution valid?

[stefan_brauneis]

Hi Holger King,

from my point of view this is exactly the way the solution should work to separate the navigation.xml and the search.xml deployment. Or in other words: Deploy the portal.xml-files into two different SAP NetWeaver Portals.

However, I do not know the exact capabilitys and the exact variables and syntax of the ActivatePortalXML-Script.

So I hope somebody from eSpirit can answer the question how the variables can be set dynamically during an action entry.

Best regards,

Stefan Brauneis

[king]

Dear community,

the initial proposed way to overwrite the configuration attribute "urlPrefixActivationClient" (that references the HLP-BP ContentCreatorClient shell script) with an individual value will not help:

//!Beanshell
startNodes = context.getProperty("portalEntryPoints");
context.setProperty("urlPrefixActivationClient", "/opt/wcms/fs4/contentCreatorClient/runClient_search.sh");
context.logInfo("prop-Value: " + context.getProperty("urlPrefixActivationClient"));
de.espirit.firstspirit.opt.portal.script.ActivatePortalXml.execute(context, startNodes);

The reason: the FirstSpirit "fs-portal.fsm" module seems to read the project's module configuration each time the "execute()" method is being executed. With that config file reading mechanism, each attribut is set into the scheduler context again. Already existing ones will be replaced. So the initial overwritten value for "urlPrefixActivationClient" (see code above) has gone again.

The only way to solve that problem is to react on the XML type parameters "content" and "search" that are passed to the configured script (here: "runClient.sh"). This means a little change that might look like:

case $CREATION_MODE in
"content")
        SERVER_USER=<user>
        SERVER_PASSWD=<password>
        SERVER_URL=<scheme>://<sap_host_for_navi_registrations>:<port>
        ;;
"search")
        SERVER_USER=<user>
        SERVER_PASSWD=<password>
        SERVER_URL=<scheme>://<sap_host_for_search_registrations>:<port>
        ;;
esac