Action: Update Set / Update Application Mismatch #66
Conversation
…trieves an array of sys ids containing the sys id of updates that belong to a different application than the one set on the update set. This is serving as a proof of concept of the idea. If I were to build a more robust version, I'd build it in global instead of having it be scoped so I could leverage look up record and look up records steps in the action as well as use an step to create a task or even make an approval and have it fix the mismatch upon the approval being approved.
|
✅ Valid PR for ActionPack Thank you for your contribution. This PR complies with the CONTRIBUTING.md. |
1shabby
changed the title
SapphicFire
left a comment
SapphicFire
left a comment
There was a problem hiding this comment.
Please update your script and consider using the JSON Parser step so you can process the objects, or instead provide them as a record list output or equivalent.
| var updateSetGR = new GlideRecord('sys_update_set'); | ||
| updateSetGR.get('sys_id',updateSetID); // Get the update set for the provided ID. | ||
| | ||
| var updatesGR = new GlideRecord('sys_update_xml'); | ||
| updatesGR.get('update_set',updateSetID); // Get the updates for the update set provided. | ||
| | ||
| while(updatesGR.next()){ | ||
| if(updateSetGR.application != updatesGR.application){ // If the application doesn't match between update set and update | ||
| flagged.push(JSON.stringify(updatesGR)); // Push stringified update record to flagged array | ||
| } | ||
| } | ||
| |
There was a problem hiding this comment.
Instead of comparing GlideElements, compare the IDs through .getValue()
What is the intent/value of pushing the whole stringified records back? How is a consumer of this action going to work with that, instead of using a JSON parser step or equivalent. Consider swapping to that?
There was a problem hiding this comment.
I sent the data back in that form just because it was a basic approach and I was curious as more of a proof of concept. This also being an action rather than a flow I tried to keep it really basic to the core functionality of finding the problematic records. I'm imagining a second action to actually consume the data from this action that way it's more modular in nature, but I'm also not an architect so if you think it'd make more sense in one action I'm all ears!
There was a problem hiding this comment.
Earlier, I had tried just using the non-stringified record since that would be of great value to the user, however I was getting "Could not serialize value" as an error when trying to pass the GlideRecord object through to the array.
I did have some luck by creating my own object with info I cared about and passing that through however. I've got a working version on my PDI that returns the objects, I can push it to my fork and merge again if you'd like. Not sure how you want to handle it
Working Version:
Failing Version:
There was a problem hiding this comment.
There is a special type called Records, which is the ideal style of output for this. But I'm happy to push forward with this, is the live version working as expected?
|
This is a great idea - I'd like to understand your mention of using Global instead, the key issue with querying these tables is that the instance involved wouldn't have the Flow Designer property set to allow those system tables be selected. There isn't a scope restraint in play, though I'm happy for you to share info if you think I'm wrong |
Thanks! The reason I mentioned doing it in global instead is so we can leverage the "look up record" & "look up records" steps instead doing it all in a script step. If I just wanted to script this, I'd do it in a script include and reference it here instead, but I can't use those steps due to the tables I'm using being in global. Though I may be wrong, and I'd be happy to be proven as such |
… I needed to create my own object as there were some complications in just passing the GlideRecord object back as an output.
2 participants
Built a basic flow action that takes in an update set sys id, then retrieves an array of sys ids containing the sys id of updates that belong to a different application than the one set on the update set. This is serving as a proof of concept of the idea. If I were to build a more robust version, I'd build it in global instead of having it be scoped so I could leverage look up record and look up records steps in the action as well as use an step to create a task or even make an approval and have it fix the mismatch upon the approval being approved.