Skip to Content

B1if XML Processor - muenchian-grouping

Hi All,

As of B1if version 1.22.9, the default XML processor is jrexml and the option to use the sapxml is not available to select.

With the new jrexml processor I've noticed that certain XSLT features are not working as I expect them to such as the key() which is used in the Muenchian Method for grouping/sorting XML nodes/elements.

The only work around I have at this stage is go back and develop in older versions of B1if where I can still select the sapxml processor and then import into the new version. When I run my XSLT in another application that uses the xanlan processor, the key() function works as expected, but not in B1if.

Is there a way to natively use the key() function as expected to implement the Muenchian Method with the jrexml processor in B1if?

Thanks

Cameron

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    Jun 07, 2017 at 12:30 PM

    Hi Cameron, this can only be done manually on file level. For this you need to edit the file vBIU.bfd in the group folder of your scenario step. Search for "XSLprofile" and change jrexml to sapxml or back around again. We recommend to choose jrexml because sapxml is outdated and we need move to jrexml in the future anyhow.

    Regards, Nicolas

    Add comment
    10|10000 characters needed characters exceeded

    • Thanks Nicolas,

      This is what I ended up doing and I got it working, but as Peter mentioned, this is still using the SAPXML processor. For me for now though that is okay until SAPXML is completely removed from B1if.

      Regards

      Cameron

  • Jun 07, 2017 at 01:20 PM

    Dear Cameron,

    The SAP XML Toolkit did support the draft version of XSLT 1.1. This never had got to an official standard though. SAP XML Toolkit in the meantime has discontinued support, that’s why we in turn must discontinue it as well.

    The used XML / XSLT processor of the Java JDK on the other hand side supports the official XSLT version 1.0.

    Concretely, the processor is Apache Xerces for XML and Apache Xalan/XSLTC for XSLT. B1i internally entirely uses the XSLTC variant for XSLT processing because this is the just-in-time compiling processor that benefits from a performance boost by compilation and subsequent re-use of a stylesheet.

    Therefore, the rules / capabilities of Xalan/XSLTC hold when considering the things that are possible / do work.

    The documentation for Xalan can be found here: https://xml.apache.org/xalan-j/

    And the more specific XSLTC deviations / hints are documented there: https://xml.apache.org/xalan-j/xsltc/index.html

    In general, the XSLT 1.1 draft has some few, but substantial new features not found in the XSLT 1.0 spec. But they entirely have been supplied / compensated by the EXSLT extension functions, as concretely documented here for XSLTC: https://xml.apache.org/xalan-j/extensions_xsltc.html#exslt_ext

    Both versions of the XSLT processors roughly supply similar features (whereas the JDK homed processor is richer concerning usage of embedded Java), but in turn the resulting stylesheet-syntax unfortunately might get incompatible to each other (what could be an issue in migration projects).

    Coming back to the key() function, it should be available in XSLTC as well as it is part of the XSLT 1.0 standard: https://xml.apache.org/xalan-j/xsltc/xsl_key_design.html

    So please give more details about what concretely goes wrong with the key() function according to the (XSLT 1.0 / XSLTC) spec / documentation.

    The SAP XML toolkit is not a reference for that, as it on the one hand side sticks to XSLT 1.1 (what should not mean a deviation for the well-known XSLT 1.0 features), but more importantly was known to interpret the XSLT standard in a somewhat fuzzy way when coming to subtle details.

    Thus, the key() function as well should work for the Java XML Toolkit if used conforming to the XSLT 1.0 Standard.

    Add comment
    10|10000 characters needed characters exceeded