Clarity

Expand all | Collapse all

Problem to change a dynamic lookup query

  • 1.  Problem to change a dynamic lookup query

    Posted Nov 05, 2015 07:44 AM

    Hi guys,

     

    I am trying to change a query from a lookup that is already in use at an object attribute and CA PPM is not showing the "Save and Continue" button on the query tab of the lookup.

     

    i had just updated to version 14.3!

     

    Thanks for your time.



  • 2.  Re: Problem to change a dynamic lookup query

    Posted Nov 05, 2015 07:54 AM

    Is it system-restricted?

     

    Not had a problem updating custom lookup-queries that are in use before now, unless something has changed to prevent this in 14.3? If it is custom, can it be changed through XOG?



  • 3.  Re: Problem to change a dynamic lookup query

    Posted Nov 05, 2015 08:11 AM

    Hi Dave, it is a custom lookup. I try updating the query using XOG and it works. I guess it is a new feature of 14.3.



  • 4.  Re: Problem to change a dynamic lookup query

    Posted Nov 05, 2015 08:18 AM

    Hmmm, that doesn't sound very helpful of 14.3 does it - making it harder for system-admins to do their job

     

    (I'll reserve a proper "rant"  about that until I know more though)

     

     



  • 5.  Re: Problem to change a dynamic lookup query

    Posted Nov 06, 2015 05:07 PM

    I have been doing some checking and found that this change came about through a need to address a defect:

     

    https://support.ca.com/phpdocs/7/5590/5590_r143_resolved_defects.html

     

    CLRT-77011 (S2) - BPM-0519: Internal Process Engine Error. Contact your site administrator (Object with name ’’ refers to object ’’ bound to the instance ’’ is not found).

     

    Synopsis:
    Some processes of the customer is failing with a BPM-0519: Internal Process Engine Error. Contact your site administrator (Object with name ’’ refers to object ’’ bound to the instance ’’ is not found) error message.

     

    Steps to Reproduce:
    1. Create a new object: "Objeto Vinculado"
    2. Create a new lookup attribute: "Resource that will receive action item" Use lookup: SCH_BROWSE_RESOURCE
    3. Add this new attribute to the mais view of this object.
    4. Go to Other Work object and create a new lookup attribute: "Objeto Vinculado" Use the lookup: OBJECT_LOOKUP_OBJ_VINCULADO
    5. Add this new attribute to the view of the object Other Work.
    6. Go to the lookup (OBJECT_LOOKUP_OBJ_VINCULADO) > Go to Query tab and click on Save and Continue.
    7. Verify if in the next page (Parent Window) the Hidden Key is "odf_pk".
    8. Create a new Process "You can give any name"
    9. In the Object tab, Set Other Work object as the Primary Object Add "Objeto Vinculado" as a Linked Object.
    10. Create a new step that send an action item to the attribute "Resource that will receive action item" of Objeto Vinculado object.
    11. Create a new instance of the Objeto Vinculado object and select a resource for the attribute "Resource that will receive action item", select a resource that has no access rights to Other Work object.
    12. Create a new instance of Other Work and in the Objeto Vinculado attribute, select the instance created in the previously step.
    13. Access Processes tab and execute the process created.

     

    Expected: Process continue the workflow normally.

     

    Actual: BPM-0519 error message and process failed.

     

    We realise that relating this defect to that impact isn't at all going to be an obvious one, and are planning to create a knowledge document to help bridge them, however this change is intended and for this reason.



  • 6.  Re: Problem to change a dynamic lookup query

    Broadcom Employee
    Posted Nov 06, 2015 05:53 PM

    This feature was introduced to avoid Clarity processes from erroring out due to changes to a lookup hidden key. This feature has been applied globally though. It should have been put in place only for those lookups which are used in clarity processes.



  • 7.  Re: Problem to change a dynamic lookup query

    Posted Nov 09, 2015 03:42 AM

    Thanks Nick/Ravi for the explanation"

     

    But re : "It should have been put in place only for those lookups which are used in clarity processes" - I would go further ; "It should have been put in place only for those lookups which are used in  active clarity processes which currently have in-progress instances" - this way, the supported workaround would be for the admin to complete those running-processes (somehow) and then they could "safely" amend the query.

     

    In the proposed KB article, it would also be useful if there were a bit of SQL which would show the "blocking processes" for a lookup to help admins?



  • 8.  Re: Problem to change a dynamic lookup query

    Posted Nov 09, 2015 07:25 AM

    Guys, thansk for the answers!

     

    David, i agree with you. How could we say to a costumer that now in this new version it is not possible to include another collumn in a lookup because it has already been created? Lots of lookups are not used in processes.

     

    This is a major step back don't you think?



  • 9.  Re: Problem to change a dynamic lookup query

    Posted Nov 09, 2015 07:44 AM

    I do!



  • 10.  Re: Problem to change a dynamic lookup query

    Posted Nov 09, 2015 10:19 AM

    These are good points but please remember the defect exposes one aspect of the issue, the fix/change may be appropriate beyond this scope also.



  • 11.  Re: Problem to change a dynamic lookup query

    Posted Nov 09, 2015 10:55 AM

    ...which of course the KB article will also explain; so that application administrators will know when they can and can not update an important dynamic-lookup query...

     

    ( and rereading that CLRT text that Nick posted earlier, I think I misunderstood the scenario anyway - its not explicitly related to running processes is it, its to do with the process setup - strange then that the "fix" would be to prevent something to do with dynamic-lookups rather than correcting something to do with the process-validation - other aspects of the application will set a process definition to "draft" when its being editted and then prevent "validation" if there is anything "wrong", perhaps this "fix" should do the same sort of thing? Sorry I'm rambling on a bit here and commenting on something that I barely know any detail of, this could (is?) be much more complicated than I am making out - however the point that fixes should never break well-used existing-functionality remains relevant I think )



  • 12.  Re: Problem to change a dynamic lookup query

    Posted Nov 09, 2015 03:53 PM

    I already have customers complaining about this...

     

    Also, bear in mind that when customers are migrating from 13.3 and 14.1 they will be adopting DW - therefore they may need to change several lookups to add LAST_UPDATED_DATE,  LANGUAGE_CODE and LANGUAGE_ID.



  • 13.  Re: Problem to change a dynamic lookup query

    Posted Mar 08, 2016 05:53 AM

    Hi Nick,

    Quick question on this thread.

    I see the save and continue button has been removed intentionally and there is a current design.

    I have a customer who is complaining and I am sure more customer's will complain.

    The customer would like to know what their users will have to do to change or update lookup query after using it for attributes?

    Could you kindly please help.

    Thank you.



  • 14.  Re: Problem to change a dynamic lookup query

    Posted Mar 08, 2016 10:12 AM

    Some have found that updating the lookup's query via XOG will work, but caution should be taken as the query changes may result in incompatibilities (or at the least, have the potential to cause the known defect above to occur).



  • 15.  Re: Problem to change a dynamic lookup query

    Posted Oct 11, 2016 07:27 AM

    I have experienced the same issue going from 13.3 to 14.3. In 13.3 I could always change a dynamic lookup. In 14.3 I will have to remove the field using the lookup which releases the lookup to be edited and saved. Then update the dynamic lookup and redo the field (besides making scripts to move data from one field to another).

     

    It is quite a huge operation which will impact users. If this can be fixed then please do so :-) (not to happy by XOG in new lookup SQL).

     

    BR/Tonny