Content Management and Capture

 View Only

  • 1.  FNCM: set attribute == modify attribute ???

    IBM Champion
    Posted Wed March 13, 2024 03:08 PM
    Edited by Kristen Park Tue March 19, 2024 11:50 AM

    Hi,

    seems I'm getting high nosed after 22 years with FileNet Content Manager and was thinking nothing could really, really surprise me. I was wrong...

    We have a customer who - for compliance reasons -needs to audit changes to his custom attributes. The code that changes document attributes has been running unchanged for decades.

    Now with our first implementation of the audit concept (estimated 7 TB for 5 years are no problem) he changed one attribute and - lo and behold - the audit log shows ALL properties as being changed.

    Turns out the programmer decades ago was kinda lazy and just set ALL properties, be they modified or not. So you see previous value of property A = "ABC", new value is "ABC". This was never really uncovered as at least ACCE and ICD do it 'properly' (in lack of a better word).

    I strongly feel this is a design flaw if not a bug. CPE should compare old and new and decide if a modification is ongoing. 

    E.g. Oracle , when setting a column value to the same as previous, will NOT fire a change trigger.

    Or am I overlooking something?

    Kind regards,

    Gerold


    #IBMChampion


    ------------------------------
    Gerold Krommer
    ------------------------------



  • 2.  RE: FNCM: set attribute == modify attribute ???

    Posted Thu March 14, 2024 08:58 AM

    Hi Gerold,

    I can see your point where you expect same values to not be recorded in the changed properties list however consider how IBM implemented property-value changes via the API. When we set the values of an object those are pending changes when we call SAVE to persist those changes the repository knows what has changed and what action the user wants to perform create/updated/delete. It would be inefficient for CPE to evaluate the updated object to existing object values aside from a sequence number check, logically whatever properties the user or external entity has changed is persisted as a change even if the value is the same. Does that make sense?



    ------------------------------
    Jay Bowen
    ------------------------------

    Original Message


  • 3.  RE: FNCM: set attribute == modify attribute ???

    IBM Champion
    Posted Thu March 14, 2024 09:19 AM
    Edited by Kristen Park Tue March 19, 2024 11:51 AM

    Jay,

    thanks for the comments... I knew the 'philosophical' argument would come up. When I set an attribute it is a 'fresh' (and therefore modified) instance. 

    I see the point, it is just completely impractical and counterintuitive. Instead of having a central place to check (CPE) I require all applications to cooperate and check themselves. Sometimes if the customer does not own the code this might even be impossible.

    The problem surfaced in ICN where the customer modified a few properties and the History-Tab shows an endless list of modified properties which aren't modified.

    How do Hyland and OpenText handle this (as you seem to know them too)? And as I mentioned in Oracle database a change trigger only fires if the value of the column in question is REALLY different to the previous value. I know not quite the same (same, same but different as they say in Thailand) but sufficiently similar.

    Thanks,

    Gerold

    #IBMChampion

    ------------------------------
    Gerold Krommer
    ------------------------------

    Original Message


  • 4.  RE: FNCM: set attribute == modify attribute ???

    Posted Thu March 14, 2024 10:02 AM

    Hi Gerold, 

    I have not looked into OnBase or OpenText auditing where the value set is the existing value to know if that will persist a change of all properties or just changed properties.  OnBase and OpenText tables have a row for each property value so a single doc with ten properties is ten rows versus an expanding docversion + LOS type T.  Even without auditing there is bloat in the DB with audit tables many times the size of the primary data tables. 

    Going back to your CPE issue you could use a change preprocessor and do your own property inspection if you really wanted to implement this.  Or, get a hold of that programmer and ask him/her what they were thinking : )



    ------------------------------
    Jay Bowen
    ------------------------------

    Original Message


  • 5.  RE: FNCM: set attribute == modify attribute ???

    IBM Champion
    Posted Tue March 26, 2024 10:35 AM
    Edited by Gerold Krommer Tue March 26, 2024 10:37 AM

    Jay,

    >r, get a hold of that programmer and ask him/her what they were thinking : )

    True, but we have (actually many) cases where properties of documents are (periodically) enriched from 3rd party (legacy) systems and nobody - not even the external app - knows what has been updated. Fortunately, customers are just about beginning to SERIOUSLY look into auditing. In my 'enrichment' scenario every single document would get an update audit every time... a horror.  The result is meaningless mess! The only way out currently would be to have the update program themselves to read the properties and manually compare every single old and new value an only update the changed ones.

    >if you really wanted to implement this...

    Yes, I wanted but failed miserably.

    What I expected in a preprocessor with such a constellation (I have written a few trivial preprocessors, so I'm by no means a preprocesor expert) :

    1. The source object would contain the properties of the document BEVOR update
    2. The PendingActions list would contain a parameter bag specifying (as key/value pairs) which attributes have been modified to which new values

    Turns out reality is:

    1. The source object contains the properties of the document AFTER update
    2. The parameter bag is empty

    So there is no way to achieve the desired result!

    But I discovered another weird behavior.

    When I modify a property  to a different value (ACCE or ICN does not matter) an audit log entry is generated AND the preprocesor runs.

    When I modify a property to the same value and audit log is created (this is the original issue) but the preprocessor does NOT run. The reason might be the following sentence in the java docs

    "If there are dirty properties in the property cache when save() is called, the API automatically creates an instance of an Update pending action and adds it to the underlying object's PendingActions collection."

    My interpretation is that setting a property to the same value as before doesn't make the property cache dirty and no Pending Actions are needed and therefor the preprocesor does not run.

    We have now a situation where setting a property to the same value as bevore is considered a change in the audit subsystem, but isn't considered a change when running a change preprocessor. A clear contradiction to me..

    Any thoughts?

    /Gerold



    ------------------------------
    Gerold Krommer
    ------------------------------

    Original Message


  • 6.  RE: FNCM: set attribute == modify attribute ???

    Posted Tue April 16, 2024 10:49 AM

    Hi Gerold, 

    Wow that is some deep debugging you have going on. As you mention this is a contradiction my first thought is "are you sure?" it doesn't make sense to me at all.  Are you able to set a property to the same value such as document title and view the pending actions in IDE before you object.save(refresh) and see if there is a pending action aka dirty property?  I can't imagine there is anything in jace.jar or fn.dll doc object APIs that are property.value = "ABC" and an inline filter that says "I am already ABC so no need to make the property dirty".  Logically reasoning this out it should be property set, dirty, +pending action, object.save to persist action > RPC > Server "what actions pending?" > Do it. 



    ------------------------------
    Jay Bowen
    ------------------------------

    Original Message


  • 7.  RE: FNCM: set attribute == modify attribute ???

    IBM Champion
    Posted Wed April 17, 2024 02:38 AM

    Hi Gerold,

    we have implemented a requirement for a customer that basically writes its own audit log for an explicit property and performs a few additional actions.

    We implemented this with a PreProcessor:

    The SourceObject contains the new value - you've already recognized that. We check whether the value has actually been changed by retrieving the original status of the (persisted) document:

    Document updated = (Document) sourceObject;
    Document origin = Factory.Document.fetchInstance(updated.getObjectStore(), updated.get_Id(), null);

    However, I certainly don't want to have to do such a round trip with every update. But maybe this will help you to become a PreProcessor expert (if that is your goal ;-))

    Regards



    ------------------------------
    Christoph Sünderkamp
    ------------------------------

    Original Message