Content Management and Capture

 View Only
  • 1.  FileNet 5.5.8 getClassName return GUID instead of Symbolic name

    Posted Thu February 08, 2024 07:11 PM

    Hi,

    I am trying to get the document class name for the incoming document inside the pre-processor. (code snip as below).  I expect "sourceObj.getClassName()" will return the class symbolic name. However, for some document classes, it return GUID instead. Any ideas?

    import com.filenet.api.action.Checkin;
    import com.filenet.api.action.Create;
    import com.filenet.api.action.PendingAction;
    import com.filenet.api.action.Update;
    import com.filenet.api.collection.StringList;
    import com.filenet.api.core.Document;
    import com.filenet.api.core.IndependentlyPersistableObject;
    import com.filenet.api.engine.ChangePreprocessor;
    import com.filenet.api.engine.HandlerCallContext;

    import java.util.Iterator;

    public class PreProcessorValidate implements ChangePreprocessor {

    public boolean preprocessObjectChange(IndependentlyPersistableObject sourceObj) {

    boolean validate = false;
    PendingAction[] actions = sourceObj.getPendingActions();

    // only validate for check in, update, and create
    for (PendingAction action : actions) {
    if (action instanceof Checkin || action instanceof Update || action instanceof Create) {
    validate = true;
    System.out.println(action.toString());
    }
    }

           System.out.println("classname="+sourceObj.getClassName());

    Thanks for any help.

    Wentao



    ------------------------------
    WENTAO LU
    ------------------------------


  • 2.  RE: FileNet 5.5.8 getClassName return GUID instead of Symbolic name

    Posted Fri February 09, 2024 02:55 PM

    Hello Wentao.  I'm surprised by this, as usually the getClassName() method does return a symbolic name.  I'm guessing that the sourceObj that was passed in must not be fully populated in the case where it returns a guid string.  I would suggest fetching the ClassDescription for that object, and then getting the symbolic name from the ClassDescription:

        ClassDescription cd = sourceObject.fetchProperty(PropertyNames.CLASS_DESCRIPTION, null);

        name = cd.get_SymbolicName();

    (Note that I have not tried this, so it may need some adjusting, and possibly won't solve your issue, but my guess is that it will)

    Regards,

    Joe



    ------------------------------
    Joe Raby
    ------------------------------



  • 3.  RE: FileNet 5.5.8 getClassName return GUID instead of Symbolic name

    Posted Fri February 09, 2024 05:13 PM

    Thanks. Actually, it seems no need to do a fetch.  I tested below code and it works.

    sourceObj.get_ClassDescription().get_SymbolicName() 

    We use getClassName() a lot, but fortunately this issue seems happened only on preprofessor, not on event action. 

     



    ------------------------------
    WENTAO LU
    ------------------------------



  • 4.  RE: FileNet 5.5.8 getClassName return GUID instead of Symbolic name

    Posted Mon February 12, 2024 05:43 AM

    Did you open a case (PMR) for this?  Because documentation for 5.5.12, 5.5.11 and 5.5.x says:
    "Returns the identity of the metadata class from which this object is instantiated"

    while the "old" documentation for 5.2.1 says:
    "Returns the name of the class from which this object is instantiated."

    The identity can be also symbolic name but the documentation should not be ambigious.... and it can't behave differently in changepreprocessor than in eventaction (without having it documented).



    ------------------------------
    Marcel Kostal
    ------------------------------



  • 5.  RE: FileNet 5.5.8 getClassName return GUID instead of Symbolic name

    Posted Mon March 04, 2024 12:39 PM

    It appears that your code snippet is incomplete or missing. If you are encountering issues with `getClassName()` returning GUIDs instead of symbolic names, it might be due to specific configurations or document class settings. Ensure that the document class configurations are consistent and that the pre-processor code accurately handles various document class scenarios. If the issue persists, consult the documentation for the specific document management system or platform you are using, as there may be platform-specific considerations or alternative methods to retrieve symbolic names.



    ------------------------------
    Candace M Green
    ------------------------------