Feature Discussions

[pinarodrigo]

The current implementation of the ActivatePortalXML Script from the Bosch Portal module (fs_portal.fsm) allows the use of either Store Element IDs or Store Element Reference Names as input for the "portalEntryPoints" variable:

But the Script fails everytime the reference name of a Root element is used, see following snippet from the log of a test run:

ActivatePortalXml' - schedule entry 'Fulldeployment wcms_c NIGHTLY' (id=3055066)

INFO  05.02.2013 18:08:25.760 {seID=3055066} (de.espirit.firstspirit.impl.access.ScriptContextImpl): === GeneratePortalXml v4.2.476 ===

INFO  05.02.2013 18:08:25.761 {seID=3055066} (de.espirit.firstspirit.store.access.AccessStoreBuilder): SITESTORE loaded in 0ms

ERROR 05.02.2013 18:08:29.506 {seID=3055066} (de.espirit.firstspirit.impl.access.ScriptContextImpl): start-node not found: root

INFO  05.02.2013 18:08:29.513 {seID=3055066} (de.espirit.firstspirit.impl.access.ScriptContextImpl): generate xml for portal entry point: Bosch GlobalNet

In this case the reference name "root" corresponding to the SiteStore Root Element was used as the value, the script runs successfully if the ID of the SiteStore Root Element ("2912717") is used instead of its reference name ("root").

Our assumption is that maybe a deprecated API, accessing only Child elements, is used in the Portal module source code, since the "Store.getStoreElement()" method documentation apparently shows that this method (new since 4.0.17) fetches store elements regardless of its position in the hierarchy .

[king]

Hi Rodrigo,

yeah you're absolutely right. It seems to be, that the following class, that is part of the FirstSpirit standard SAP Netweaver Portal module (fs_portal.fsm😞

de.espirit.firstspirit.opt.portal.ActivatePortalXml

might only support reference names (UIDs) being configured within the standard properties of an "ActivatePortalXml" scheduler entry as long as no store root element is mentioned:

This is really poor, because for search XML structures the root node is mainly taken and configured.

When using FirstSpirit IDs, the problem is, that the IDs vary when exporting and re-importing the project again. So, potentially configured FirstSpirit IDs have to be updated here. To prevent that step, UIDs might really be helpful - if they would work completely!

To prevent any custom scripting and custom solution, we would like to improve the current solution within the standard implementation here as it seems to be a one liner. Just remove the DEPRECATED API by the current recommended one.

[MichaelaReydt]

Hello Rodrigo

thank you for your idea to improve FirstSpirit. It is important for us to learn from the experiences of our customers and partners. For this reason we appreciate feedback and any suggestion.

We have evaluated the issue once again, but have no plans for a realisation in the near future. Therefore, we cannot consider your feature request at this time.

You can find more details about our feature selection process in our Features Policy.

Best regards

Michaela