LPL to derive an uppercase and lowercase version of an Alpha or Text field

The current version of the Configuration Console Reference Guide: Landmark Pattern Language (May 2022) on page 15 (in the TypeOperator section) implies that one should be able to say:

AlphaField uppercase
AlphaField lowercase

to get the uppercase or lowercase version of a text field anywhere you would otherwise use AlphaField.

Configuration Console, however, considers these type operators to be a syntax violation.

Support is telling me that they checked with the Landmark development team and that these type operators have not been implemented and there is no ETA for when (or if) they will be. It'll be a future "enhancement".

For uppercase, at the expense of an extra user defined field, one can fairly easily do this:

UpperAlphaField is a DerivedField
    type is AlphaUpper size ##
    return AlphaField

I've been trying to brainstorm what a suitable equivalent would be to obtain a lowercase version, but there isn't an AlphaLower type.

Has anyone run into this problem before? If so, how did you solve it in LPL?

If I took the time to open an official enhancement request to ask that the uppercase and lowercase type operators get implemented, would others support it?

Find more posts tagged with

LSF/Landmark Development

Accepted answers

All comments

andy

I think you can use Java formatter to accomplish this. Let me see if I can find any example...

https://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html

andy

So I've used this in an action rule to ensure the address is all uppercase...

PostalAddress.DeliveryAddress.AddressLine1 = PostalAddress.DeliveryAddress.AddressLine1 using "%1S"

What's the context in which you are trying to set uppercase /lowercase? Just display or set a persistent value?

andy

FYI you could probably also use "%1s" for lowercase.

andy

Nevermind, "%1s" only returns string as is. You could still use "%1S" for uppercase and not have to define any user fields.

cleverly

I'm trying to generate a persistent value.

I came up with this total brute force hack, but it would require a lot more code to extend it from US-ASCII to even just a reasonable Latin subset of UTF-8. (We have business units in South America.)

Local Fields
    Counter is Numeric size 2
    Length  is Numeric size 2
    Char    is Alpha size 1

Derived Fields
    LowerAlphaField is a DerivedField
        type is Alpha size ##
        LowerAlphaField = ""
        Counter = 1
        Length = AlphaField size

        while (Counter <= Length)
            Char = AlphaField[Counter]
            Counter += 1
            if (Char = "A")
                LowerAlphaField += "a"
            else
            if (Char = "B")
                LowerAlphaField += "b"
            else
            if (Char = "C")
                LowerAlphaField += "c"
            else
            if (Char = "D")
                LowerAlphaField += "d"
            else
            if (Char = "E")
                LowerAlphaField += "e"
            else
            if (Char = "F")
                LowerAlphaField += "f"
            else
            if (Char = "G")
                LowerAlphaField += "g"
            else
            if (Char = "H")
                LowerAlphaField += "h"
            else
            if (Char = "I")
                LowerAlphaField += "i"
            else
            if (Char = "J")
                LowerAlphaField += "j"
            else
            if (Char = "K")
                LowerAlphaField += "k"
            else
            if (Char = "L")
                LowerAlphaField += "l"
            else
            if (Char = "M")
                LowerAlphaField += "m"
            else
            if (Char = "N")
                LowerAlphaField += "n"
            else
            if (Char = "O")
                LowerAlphaField += "o"
            else
            if (Char = "P")
                LowerAlphaField += "p"
            else
            if (Char = "Q")
                LowerAlphaField += "q"
            else
            if (Char = "R")
                LowerAlphaField += "r"
            else
            if (Char = "S")
                LowerAlphaField += "s"
            else
            if (Char = "T")
                LowerAlphaField += "t"
            else
            if (Char = "U")
                LowerAlphaField += "u"
            else
            if (Char = "V")
                LowerAlphaField += "v"
            else
            if (Char = "W")
                LowerAlphaField += "w"
            else
            if (Char = "X")
                LowerAlphaField += "x"
            else
            if (Char = "Y")
                LowerAlphaField += "y"
            else
            if (Char = "Z")
                LowerAlphaField += "z"
            else
                LowerAlphaField += Char
    return LowerAlphaField

Poking around FSM business classes business logic, I found the Supplier business class in the Procurement module uses com.lawson.apps.procurement.base.StringUtils.convertToUpperCase(DoingBusinessAs). I don't know whether there is a corresponding convertToLowerCase() method, but even if there were user defined business classes aren't whitelisted to invoke com.lawson.apps.procurement.base.StringUtils.* (I tried! :-).

Your using using "%1S" is definitely the cleanest way to get an uppercase version.

andy

Good detective work. I've previously tried using that StringUtils as well but as you said it appears to be blocked contextually in other modules, and coincidentally there isn't a lowercase method in that package anyway...

trimLeadingSpaces
convertToUpperCase
leadingZeros
stripNonAlphaNumeric
stripNonUnicode

You might be able to add an ECMA script in Config Console > Data Area > Scripts that just invokes the JS function toLowerCase(), and then invoke the script in your LPL. Its been a while since I've explored adding a script there, so it may no longer be supported.

cleverly

I had to go to the ScriptEngine and activate the engine, but I was able to create a script (named "TEST"). I can invoke it from LPL, but I don't know how to pass variables in or out.

As a simple test case I created a new User Business Class with a Derived Field:

    Derived Fields
        X is a DerivedField
            type is Numeric size 10
            X = 0
            invoke script "TEST"
            return X

When my "TEST" script contains:

X = 2+2;

Then the derived field returns 0.

When my "TEST" script contains:

X = 2/0;

Then my derived field's value is:

ERROR retrieving field value: Script execution failed for "TEST"

So it is at least evaluating it.

Do you happen to remember anything more about how these scripts are supposed to work? There doesn't seem to be anything in the documentation about them.

cleverly

Here is another way — and probably the one I'll go with for now — using LPL's select statement and an XPath expression (sadly it looks like only XPath 1.0 functions are supported, so no upper-case() or lower-case() from XPath 2.0, but we can get there with translate()). Note for anyone wanting to copy and paste—I added extra newlines in the XPath to make the output more readable here in this forum. Config Console won't accept that. The XPath statement has to be on a single line.

MixedCase is a BusinessClass
    prefix is cfg

    Ontology
        symbolic key is MixedCase

    Derived Fields
        AsXML is a DerivedField
            type is XMLDocument
            return ""

        UpperCase is a DerivedField
            type is Alpha size 30
            return AsXML select "translate(/xml/text(),
                'abcdefghijklmnopqrstuvwxyz',
                'ABCDEFGHIJKLMNOPQRSTUVWXYZ')"

        LowerCase is a DerivedField
            type is Alpha size 45
            return AsXML select "translate(/xml/text(),
                'ABCDEFGHIJKLMNOPQRSTUVWXYZ',
                'abcdefghijklmnopqrstuvwxyz')"

Yields:

On a related note, I discovered the LPL documentation's statement:

// if the field is any other type, the SelectStatement is treated as a Regular Expression

is vaporware too, just like the LPL lowercase and uppercase type operators. If it worked (perhaps by selecting whatever matched the first capturing set of parenthesis in the regular expression) I can see it being very useful to decode and extract data.

Role Based Security Webinar-20200310 1503-1.mp4

andy

Oh, clever! I've never used that select operator. Definitely going to check that out. The regex parsing didn't function though?

cleverly

The selectors work if the field is an XMLDocument or a JSONObject, but the regular expression syntax for other types of field doesn't. Based on the error message it looks like future functionality that hasn't been implemented yet.

Copyright © 2025 Infor. All rights reserved.