Search code examples
guidewiregosu

What is a suitable replacement for the deprecated setFieldValue() methods?

A common Cloud Assurance violation is usage of the various versions of the setFieldValue() method, which is deprecated and therefore not allowed by Guidewire Cloud Standards. What is a suitable replacement for this method so we can resolve our Cloud Assurance violations?

There are a couple different versions of setFieldValue(), which are defined in the interface com.guidewire.pl.persistence.core.BeanMethods and have a few different implementation classes:

    @Deprecated
    void setFieldValue(IEntityPropertyInfo field, Object value);
    @Deprecated
    void setFieldValue(String field, Object value);

Not only are these deprecated, but they are found in hidden packages, which are also not allowed by Guidewire Cloud Standards.

If standard getter and setter properties are not available, how else can we set values for these fields?

Solution

  • Typically, there is a reason that getter and setter properties are not available. There could be specific rules or validations that must be performed, or a specific process that must be followed. There may also be legal reasons, for instance attempting to change the value on a bound and locked Policy is not allowed.

    setFieldValue() uses reflection to set values and as a result, it can circumvent validations built into the system and lead to data corruption. Additionally, the usage of hard coded strings for field names is brittle and against general coding best practices.

    In all xCenters (CC, BC, PC, CM) the usage of setFieldValue() has caused data corruption and significant issues in Production systems, especially if used on financial data. This is the reason the methods were deprecated in the first place.

    Depending on the state of the entity/object you are changing, the first questions to ask are:

    • Why are the standard getter and setter properties not available?
    • Is there a special process for changing these values?
    • Is there validation that needs to performed before changing these values?
    • Could changing these values cause an issue?

    If you believe you have a valid business and technical reason for setting the values of these properties directly, you may consider the following alternatives to setFieldValue().

    If the object is an Entity/Bean and you are trying to set an attribute/field value, use the set() function available on the (non instance) entity class

    • Example: policyTerm.setFieldValue("MostRecentTerm", true)
      • Replace with: PolicyTerm#MostRecentTerm.set(policyTerm, true)

    If the object is an Entity/Bean and you are trying to set the entire object by its key (rather than value) then there is currently no replacement for this case so you may continue to use it. You may still need to discuss with your CA contact if this is appropriate and if they can provide a temporary allowance.

    • Example: cost.setFieldValue("PersonalVehicleCov", _covID)
      • This does not work: cost#PersonalVehicleCov.set(_covID)

    If the object is not an Entity/Bean or not DB backed, the standard does not apply and no replacement is necessary. You may still need to discuss with your CA contact if this is appropriate and if they can provide a temporary allowance.

    • Example: costData.setFieldValue()
      • CostData object is not an Entity so this does not work

    If the object is a scheduled item, you should use PropertyInfos and ValueProviders rather than accessing columns directly (see various OOTB scheduled item implementations for reference)