4 Replies Latest reply on Aug 3, 2021 4:34 AM by Ronald Lubin

    Attribute being overwriten

    Ronald Lubin Guru

      Hi all,

       

      Maybe you can help me with this scenario in PIM.

       

      We configured the Business Process Management in PIM to trigger the ActiveVOS workflow whenever a user makes changes to an attribute value.  This works fine when the user makes a single attribute value change.  However, if the user makes multiple changes we noticed at time some of the changes are deleted.  After considerable amount of investigation we noticed two things are causing this issue.

       

      1: The standardizing rule will take in input blank value and output a blank value which is normal.

      2: The second thing is that since the user made multiple attribute changes that triggered the workflow multiple times.  At different times in the workflow, values were entered by the user to an attribute but the standardizing rule from the first execution of the workflow outputted blank at that time which wiped the user's value.

       

      One way to fix this is to only allow a specific attribute to execute the workflow therefore we will not have multiple execution of the workflow for one item.  Unfortunately, business does not like that approach as it will require them to always have to remember to trigger the workflow.

       

      Is there a way to allow only one workflow to be executed while the user is making changes to the attributes?  Also, perhaps the standardizing rule can be configured to not overwrite with blank when the input is blank.  Is that possible? like divert the output to something else if the input is blank..

       

      Any suggestion would help.

        • 1. Re: Attribute being overwriten
          Sathiesh M Guru

          Pls find the general guidelines on P360 usage of DQ rules

           

          DQ is most useful, if the resulting DQ status of an item is used:

          • for (manual) cleansing of data, for example in context of a workflow task that contains all items with a failed DQ status
          • in context of an automatic process like merge or import (items with a failed DQ status won't be merged)

          DQ is not recommended (and the proposal would be a customization):

          • in general, if the DQ status is not used for follow up processes as described above
          • calls to Product360 via Rest calls in a Java Transformation that are not performant and/or complex e.g.
            • usage of many input ports to gather several data. This may slow down the execution time since these fields result in a too big sql statement to be performant (3900 characters in resulting sql statement part is the limit). An example is the concatenation of dozens of text attributes.
            • solving duplication detection problems. An example would be involving item id duplication checks on products of an item which are retrieved via rest calls.
            • in general rebuilding a large portion of the hierarchical and referential Product360 data model inside a DQ rule mapplet instead of simply using only the input data from the input ports of a rule mapplet.

          In these cases one could think about avoiding usage of DQ checks and instead finding another way to reach the business goal - like a customization with extension points.

          Never do this

          • Never create, delete or modify objects in the context of the DQ execution itself.
            A good example would be to define a workflow instead, execute DQ inside the workflow and after the execution create a workflow task containing failed items.
          • Never use database connection access to our databases in DQ rules, neither for reading nor for writing. It is not supported by Product 360. If read access is needed, please use the Rest Service API (again, only read access in that case).
          • Never change our OOB rule packages like 'Informatica_PIM_Content.xml' and do not re-export OOB rules from IDQ Developer. Otherwise we can not guarantee that they still work.
          • 2. Re: Attribute being overwriten
            Ronald Lubin Guru

            Hi Sathiesh,

             

             

            Thank you for your response however the whole point of creating standardizing rules is to output the result.  I do not believe there is a way around this.  The standardizing rule was not a modified version of the OOB rule rather a new rule.  The issue is not the rule itself.  It is the fact that multiple execuion of the workflow is being triggered base on the Entity Changed setup.  In this case, we have no way around executing the workflow base on attribute changes but it is the source of the issue.

             

            Also,  this issue is not generating an error nor do we have DQ failures but we do see the impact because of the execution of multiple workflow.

            • 3. Re: Attribute being overwriten
              Sathiesh M Guru

              Also check this KB for Workflow trigger best practices

               

              Support

               

              You may need to use Trigger Grouper for capturing all changes to an Item and then create a task

              • 4. Re: Attribute being overwriten
                Ronald Lubin Guru

                Thank you Sathiesh for this.

                 

                What is trigger Grouper?  I have never heard of it.  Can you provide an example that might help me understand it.