not sure I understand the ask here, can you be more specific on what you are for.
Currently the REST api that is published by Remedy doesn't considers the Client side performance. For a Simple HTTP request that is supposed to retrieve data from a single form, it works great. The real issue comes when we try to fetch data from the related forms.
If i create an Incident and need to fetch the Email ID of the submitter's manager then there are 3 HTTP requests to be made
1. Get the Login ID of the Submitter from the Incident form
2. Get the Managers Login ID from the People form based on the Submitter's Login ID
3. Get the Managers Email ID from the People form based on the Managers Login ID fetched using step 2.
Same thing happens when we try to fetch the Incident details along with the Company Information and certain parameters of Site Information.
How its Handled now:
Currently, the way we are handling such requirements are by using any of the below 3 methods
1. Create a new field in the remedy main form(which acts as the endpoint) with workflows that populate them.
2. Create association(object) between the main form and the ancillary forms and the endpoint will have the data mentioned in the association object as well.
3. Use multiple GET requests
Drawbacks of Current approach:
Issue with the above 3 steps is either
1. Over - fetch/Under fetch of information
- we dont always get what we need, instead we get a lot of unwanted data(attributes)
2. Multiple network calls
3. Heavy Customization's that can grow unmanageable at a point of time.
- need to create a field/filter/association for each new requirement
I have posted this question to understand that if there is a plan from BMC to implement a solution for the same or is it already in place?
the join forms are how this is handled OOB.
If there is not a join that is present with the data required, you can create one and query this via the Rest API.
Is there a different approach to it. The use case is to query a forms and its multiple relationships using a single query and we do not want to put a customization in place for each business requirement. It would be great if this can be achieved using configuration over customization.
I'm not attempting to be argumentative here, just looking for your input.
You want data from multiple sources, yet don't want to make multiple calls to get it, you are unwilling to create a single point that you can call from to get all of the data you want to get.
What suggestion do you have that would allow you to make calls from multiple sources with a single call?
Oh...one thing on the 'a lot of unwanted data', you have the ability to specify exactly which fields you want returned in your result
May be something similar to Graph Walk that we already have for CMDB. Is some thing of that kind is already available for remedy as well?
unfortunately, it's not possible to limit the fields displayed if we create an association object and add it as a parameter to the rest endpoint.
the method you mentioned is only possible if a new join form is created.
Is there a different approach wherein we can get the desired info. without creating joins, associations, workflows.
Can we use a single call to retrieve the corresponding record and its related information, like what we have for CMDB Graph walk ?
I believe you are confusing the CMDB Graph Walk functionality with OOB Remedy functionality.
The Graph Walk query is a specialised function developed for the CMDB to perform actions associated with Service Models and relationships. It is specific in that it performs a function to return a defined set of data. This is a very specific function that this query performs so I believe what you are asking cannot be compared to the Graph Walk Query.
It appears you would like something similar for a specific scenario, however you need it to be dynamic (extremely) across all of Remedy/ITSM and not just perform a defined task that the Graph Walk Query does. This is a completely different requirement, therefore I don't believe you can compare the 2.
As LJ points out, as the developer you can define what data is returned based on how you create the join form and what fields are present.
Currently this is the best option available, and the most flexible.
You can also leverage the OOB joins with the Rest API as to avoid development.