CA Service Management

  • 1.  QREL in list_xx.htmpl

    Posted May 18, 2017 11:47 AM

    Hi Guys,

     

    Does someone ever tried to add a QREL search field on a list_xx.htmpl file?

     

     

    Use case : Get all the CIs which their direct parent is a particular CI. ( IE: Obtain the CIs that are linked to a meeting room)

     

     

    Thanks



  • 2.  Re: QREL in list_xx.htmpl

    Posted May 19, 2017 06:40 PM

    Hi.

    I'm quite sure that this can be done.

    Unfortunately, I would need to do some testing first, before suggesting any solution. And I don't have the ability to do so currently (vacation).

    So unless nobody else will come up with an idea, you'll need to be patient. I'll be back in one week, and will take a look at this topic again.

    Regards

    .....Michael



  • 3.  Re: QREL in list_xx.htmpl

    Posted May 21, 2017 02:25 PM

    Hi,

    seems like there is no way to pass square brakets using search inputs (like sfLookup).

     

    For example (I use chg factory) we have Special Handling BREL:

    <PDM_MACRO name=sfLookup hdr="Special Handling" attr="affected_contact.cnthandling_list.special_handling.sym" factory=special_handling>

    Which procudes this URL part:

    QBE.IN.affected_contact.cnthandling_list.special_handling.sym

    And it working great.

     

    Then going to QREL in the same way:

    <PDM_MACRO name=sfLookup hdr="Task Type" attr="id.[chg]workflow.task" factory="tskty">

    URL looks like:

    QBE.IN.id.[chg]workflow.task

    And it fails without any error message.

     

    But if you pass same condition using ADDITIONAL_WHERE:

    id.[chg]workflow.task = 'APP'

    it will work as it should, so if you need this very very very much you can apply workaround: using sfLookup as a fake input and using ADDITIONAL_WHERE to pass value from the fake input.

     

    Also, I'm hope that Michael_Mueller could provide better solution

     

    Regards,

    cdtj



  • 4.  Re: QREL in list_xx.htmpl

    Posted May 23, 2017 09:10 AM

    Imaginative idea, but good luck for the guy after me

     

    I'll keep that in mind and wait to see what Michael comes up with.



  • 5.  Re: QREL in list_xx.htmpl

    Posted May 29, 2017 06:10 AM

    Hi guys.

    I assume I promised too much . My appologize. I'm very sorry about this, especialy, I raised up the expectations that high, and forced you to be that patient. 

    Playing and digging around with this question, I had to recognize, that there are certain limits in the webengine framework.

    At least here is what I found:

    • the backend (domsrvr / DB layer)  supports queries like: give me all CI's that have a specific CI as their parent (connected by bmhier)
      cdtj already mentioned an example for these type of queries. For the above question the wherclause would look like:
      id.[child]bm_parent_hier.parent.name='Server1'
    • btw. you would get the same result with
      id.[child]bm_child_hier.parent.name='Server1'
    • Then I started with the sfLookup macro and needed to get through certain hurdles.
      • the sfLookup macro tries to use the so called COMMON_NAME attribute of the given attr.
        Unfortunately, the COMMON_NAME can not be resolved for a given attribute like "id.[child]bm_parent_hier.parent.name".
      • I replaced the pdm_macro line with the appropriate javascript call of searchFilterLookup(...) to avoid this common_name problem.
        • searchFilterLookup("Parent CI","id.[child]bm_parent_hier.parent.name","nr",1, "name", "", "false");
      • After that at least the autosuggest and lookup stuff was working.
      • I than recognized that the ADDITIONAL_WHERE clause part make sense only for a hardcoded additional search part for both searches, the autosuggest/lookup searches, and the final list_nr search.
      • After selecting the parent CI and press search, the webengine receives the appropriate information like
        • QBE.EQ.delete_flag = '0'
        • QBE.EQ.id.[child]bm_parent_hier.parent = 'F5FB4218350801F796EF000C29ABB29E'
      • based on this information the webengine tries to build a final wherclause but, unfortunately is not able to determine the data type for the term id.[child]bm_parent_hier.parent
        • 05/29 11:49:41.32 *** web:local 47780 WARNING freeaccess.spl 7254 Unable to determine data type for nr::id.[child]bm_parent_hier.parent
      • and skips the use of this specific whereclause part.
    • And that's the end , at least from my side...

     

    I think it would be  worth to raise an idea, so that the sfLookup macro would be able support QREL attribute searches ootb as well.

     

    Kind regards ( and again please excuse my misleading assumptions )

    .....Michael