Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-8180

Need a way to control what properties are serialized in maintenance documents.

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.3
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Similar issues:
      KULRICE-8179Rice KEW considers Maps as 'simple' properties and serializes them and persists them in the database.
      KULRICE-9187Maintenance framework needs a hook that gets executed prior to serialization to XML
      KULRICE-1912No way to suppress lookups (quickfinder) on maintenance doc fields
      KULRICE-11812KRAD maintenance docs break if there are lazy relationships in JPA due to copying by serialization
      KULRICE-8510Maintenance documents blow up when a property is removed and there are pre-existing documents with that property.
      KULRICE-13730Create Web Tests for KRAD Maintenance Document View Presentation Controller
      KULRICE-12033Add annotation to enable serialization opt-in / opt-out for individual maintenance doc fields
      KULRICE-9105Determine how to do a more efficient and less wasteful approach for XML object serialization for the maintenenace framework
      KULRICE-13518Create smoke test for the dd property allowsRecordDeletion
      KULRICE-13841Create controller/form for transactional documents
    • Rice Module:
      KRAD
    • Application Requirement:
      KC
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      Maint Docs are persisting the whole object tree into the document content table and this appears to be unnecessary. Is there a way to limit the serialization of properties on the maintenance documents like there is for the transactional documents? If not, can a change be made in KRAD to make the serialization of properties smarter?

        Activity

        Hide
        Sona Sona (Inactive) added a comment -

        Here is my understanding of why <workflowProperties> is not being using to limit the serialization of maintenance documents. In case of maint docs on save, the business objects for the maintenance documents are serialized to XML. Once the document is enroute, and a user opens the doc back up the business object is deserialized from the XML representation stored in KRNS_DOC_HDR_T using XStream and set on the maintenance document. Once all approvals have been gathered against the document, the document is loaded from the database deserializing the business objects from the XML content stored on KRNS_MAINT_DOC_T and the doRouteStatusChangeEvent is invoked. Only when the document is processed does the business object get persisted into the db. Until then all the data incase of maint docs is kept on the XML. This is not the case with Transactional documents where the data is stored in intermediate tables until its processed.

        https://wiki.kuali.org/display/KFSOLD/Specifying+Document+Properties+to+Serialize+for+Workflow+in+the+Data+Dictionary talks about how you can specify which properties you want to serialize. The document does say that </workflowProperties> can be used for both transactional as well as maintenance docs though I was not able to find an example where its being used in maintainence documents to specify multiple properties of a document in the rice codebase. The ones I found are serializing the main business object.

        <workflowProperties>
        <workflowPropertyGroup>
        <workflowProperty path="oldMaintainableObject.businessObject" />
        <workflowProperty path="newMaintainableObject.businessObject" />
        </workflowPropertyGroup>
        </workflowProperties>

        Show
        Sona Sona (Inactive) added a comment - Here is my understanding of why <workflowProperties> is not being using to limit the serialization of maintenance documents. In case of maint docs on save, the business objects for the maintenance documents are serialized to XML. Once the document is enroute, and a user opens the doc back up the business object is deserialized from the XML representation stored in KRNS_DOC_HDR_T using XStream and set on the maintenance document. Once all approvals have been gathered against the document, the document is loaded from the database deserializing the business objects from the XML content stored on KRNS_MAINT_DOC_T and the doRouteStatusChangeEvent is invoked. Only when the document is processed does the business object get persisted into the db. Until then all the data incase of maint docs is kept on the XML. This is not the case with Transactional documents where the data is stored in intermediate tables until its processed. https://wiki.kuali.org/display/KFSOLD/Specifying+Document+Properties+to+Serialize+for+Workflow+in+the+Data+Dictionary talks about how you can specify which properties you want to serialize. The document does say that </workflowProperties> can be used for both transactional as well as maintenance docs though I was not able to find an example where its being used in maintainence documents to specify multiple properties of a document in the rice codebase. The ones I found are serializing the main business object. <workflowProperties> <workflowPropertyGroup> <workflowProperty path="oldMaintainableObject.businessObject" /> <workflowProperty path="newMaintainableObject.businessObject" /> </workflowPropertyGroup> </workflowProperties>
        Hide
        Gayathri Athreya added a comment -

        I spoke to KFS about this per Jerry's suggestion and one way to control what gets serialized is to set the "workflow attributes" in the maintenance document data dictionary. I believe they had a similar issue and actually wrote the code that does this. Jerry however suggested during the KTI that maybe KRAD could be "smarter" about what it serializes so it may still be worth pursuing.

        Show
        Gayathri Athreya added a comment - I spoke to KFS about this per Jerry's suggestion and one way to control what gets serialized is to set the "workflow attributes" in the maintenance document data dictionary. I believe they had a similar issue and actually wrote the code that does this. Jerry however suggested during the KTI that maybe KRAD could be "smarter" about what it serializes so it may still be worth pursuing.
        Hide
        Peter Giles (Inactive) added a comment -

        Hi Gayathri, apologies if this is something we've gone over and I forgot it – Can you give a specific example of a property on a maintenance document that you wouldn't want serialized in the XML? I have a better grasp on how this applies to transactional documents than maintenance docs. Thanks!

        Show
        Peter Giles (Inactive) added a comment - Hi Gayathri, apologies if this is something we've gone over and I forgot it – Can you give a specific example of a property on a maintenance document that you wouldn't want serialized in the XML? I have a better grasp on how this applies to transactional documents than maintenance docs. Thanks!
        Hide
        Gayathri Athreya added a comment -

        If you look in our Financial Object Code Mapping maintenance document on this server (http://test.kc.kuali.org/kc-intg/portal.do?selectedTab=portalMaintenanceBody) you will notice that it links to several business objects like Unit, Rate Class Code, Rate Type Code etc. Unit itself links to Organization which in turn has collections of other BOs. While saving the Financial Object Code Mapping document, the entire object graph is saved, which means that all the Organizations and their associated collections get saved which seems unnecessary. As I noted in the previous comment, adding workflow attributes to our maintenance docs gets rid of most of this data but maybe KRAD can be smarter about the information it tries to save.

        Show
        Gayathri Athreya added a comment - If you look in our Financial Object Code Mapping maintenance document on this server ( http://test.kc.kuali.org/kc-intg/portal.do?selectedTab=portalMaintenanceBody ) you will notice that it links to several business objects like Unit, Rate Class Code, Rate Type Code etc. Unit itself links to Organization which in turn has collections of other BOs. While saving the Financial Object Code Mapping document, the entire object graph is saved, which means that all the Organizations and their associated collections get saved which seems unnecessary. As I noted in the previous comment, adding workflow attributes to our maintenance docs gets rid of most of this data but maybe KRAD can be smarter about the information it tries to save.
        Hide
        Peter Giles (Inactive) added a comment -

        Thanks Gayathri, that makes it more concrete for me. Is KC wanting us to support this sort of limiting serialization of the object tree by adding additional structure to the data dictionary, or via some specific other mechanism? Or are you hoping we can come up with a good suggestion?

        Show
        Peter Giles (Inactive) added a comment - Thanks Gayathri, that makes it more concrete for me. Is KC wanting us to support this sort of limiting serialization of the object tree by adding additional structure to the data dictionary, or via some specific other mechanism? Or are you hoping we can come up with a good suggestion?
        Hide
        Gayathri Athreya added a comment -

        Hi Peter, sorry I completely lost track of this jira. So, I have tried using workflow attributes in our maintenance documents like KFS does and it does prevent the properties from being serialized.I want to test it in a few more documents to make sure it does indeed work the way we want it to. If it does, that would be enough for the time being and I will resolve this jira. Thanks.

        Show
        Gayathri Athreya added a comment - Hi Peter, sorry I completely lost track of this jira. So, I have tried using workflow attributes in our maintenance documents like KFS does and it does prevent the properties from being serialized.I want to test it in a few more documents to make sure it does indeed work the way we want it to. If it does, that would be enough for the time being and I will resolve this jira. Thanks.
        Hide
        Corey Pedersen (Inactive) added a comment -

        Issue being set to resolved and can be reopened if further testing by Gayathri indicates need.

        Show
        Corey Pedersen (Inactive) added a comment - Issue being set to resolved and can be reopened if further testing by Gayathri indicates need.
        Hide
        Gayathri Athreya added a comment -

        Setting workflowProperties in our documentType fixes this issue, closing.

        Show
        Gayathri Athreya added a comment - Setting workflowProperties in our documentType fixes this issue, closing.

          People

          • Assignee:
            Corey Pedersen (Inactive)
            Reporter:
            Gayathri Athreya
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel