External items in ARO list

Peter_Miklian

Hi all experienced community members,

I hope this is not duplicate question in this rich forum and I'll get brilliant ideas and suggestions :)

Our customer has item list in external database and would like end users to be able to select those item(s) in ARO in the portal.

Usecase: select software to install from approved set of applications held in DB outside of SCSM.

I wonder what would be the best option, what do you recommend/use?

Some options came to my mind:

1. using simple list. Pros & cons: nicer look (dropdown), speed; no multiselect
   1. manual maintaining of local copy of the list in the ARO Simple list (drowpdown). Drawbacks: error prone, work-intensive, far from real time updates, unthinkable in case of frequent/many changes
   2. running scheduled script: export MP with AROs, pull data from external DB, edit XML list items, import XML MP, restart CB. Drawbacks: could collide with other edits. Benefits: near-realtime data
2. using ROQP (Request offering query picker). Pros & cons: search, multiselect; slow search, worse layout
   1. create custom CI (configuration item) type in SCSM. Sync items from external database using scheduled script. Benefits: near-realtime data
3. using MP Enumeration List
   1. create custom list and synchronize items from external database to it (again script import XML MP). Drawbacks: would require extension to ARO/SR class for enum mapping, I never used this type of prompt

I caught code word 'datapoint' which could be related to this topic. Is it? Could someone explain in detail/point to some relevant sources? Thanks.

Adam_Dzyacky

1. using simple list. Pros & cons: nicer look (dropdown), speed; no multiselect
   1. Exactly for the reasons you've laid out is why I wouldn't go this way. It's a lot of administrative overhead for a single process. Granted, it depends on how often you think it will change. If it's once every 6 months it's probably manageable. But again - no multiselect, there just isn't a way around that.
2. using ROQP (Request offering query picker). Pros & cons: search, multiselect; slow search, worse layout
   1. This is hands down the route I've almost always gone with. It's easy to work with. It's easy to create. Plus using the Cireson Asset Import connector you can create a connector that turns sql table rows into CIs. As far as the layout, there are two options available on the portal. Out of my own curiosity, what's not great about them?
3. using MP Enumeration List
   1. I've done something like this because I wanted to experiment with syncing Azure constructs into custom list values. It's doable, but I'd choose option 2/the CI route because it's so much easier.

I have ALWAYS gone with option two for a couple reasons:

1. The maintenance is as low as the stock SCSM connectors. Set it and forget it.
2. You get custom Configuration Items out of this process that you can use in a host of scenarios - namely automation.
3. You further enhance the overall quality of your CMDB by continuing to round out the types of data you have available.
4. In the most recent iterations of the portal, you can add the class to the list of available classes that are available via Global Search

Justin_Workman

@Peter_Miklian - I'd like to point out a couple of options. I agree with @Adam_Dzyacky that a new CI class is probably the best route. Since you're dealing with data from an external database, I would recommend using an Asset Import connector to bring that data in. That way you don't have to

I do want to point out though that you could use a simple list with the RO Toolbox and the @QueryList tag to bring in the data from SQL into the Simple List and there would be no additional management of the list needed.

Adam_Dzyacky

1. using simple list. Pros & cons: nicer look (dropdown), speed; no multiselect
   1. Exactly for the reasons you've laid out is why I wouldn't go this way. It's a lot of administrative overhead for a single process. Granted, it depends on how often you think it will change. If it's once every 6 months it's probably manageable. But again - no multiselect, there just isn't a way around that.
2. using ROQP (Request offering query picker). Pros & cons: search, multiselect; slow search, worse layout
   1. This is hands down the route I've almost always gone with. It's easy to work with. It's easy to create. Plus using the Cireson Asset Import connector you can create a connector that turns sql table rows into CIs. As far as the layout, there are two options available on the portal. Out of my own curiosity, what's not great about them?
3. using MP Enumeration List
   1. I've done something like this because I wanted to experiment with syncing Azure constructs into custom list values. It's doable, but I'd choose option 2/the CI route because it's so much easier.

I have ALWAYS gone with option two for a couple reasons:

1. The maintenance is as low as the stock SCSM connectors. Set it and forget it.
2. You get custom Configuration Items out of this process that you can use in a host of scenarios - namely automation.
3. You further enhance the overall quality of your CMDB by continuing to round out the types of data you have available.
4. In the most recent iterations of the portal, you can add the class to the list of available classes that are available via Global Search

Justin_Workman

@Peter_Miklian - I'd like to point out a couple of options. I agree with @Adam_Dzyacky that a new CI class is probably the best route. Since you're dealing with data from an external database, I would recommend using an Asset Import connector to bring that data in. That way you don't have to

I do want to point out though that you could use a simple list with the RO Toolbox and the @QueryList tag to bring in the data from SQL into the Simple List and there would be no additional management of the list needed.

Peter_Miklian

Thank you both for insightful responses.

@Justin_Workman I we casted RO toolbox off and enabled and started using ROQP. Is it able to use ROQP and RO Toolbox at once? I don't remember if this was the cause or we just didn't want to maintain 2 ways/layouts of publishing of the same content to end users. I didn't know RO Toolbox can natively pull data from external SQL database into Simple list, interesting information. Btw, middle of your answer seems to be lost :)

@Adam_Dzyacky so we'll create custom CI in SCSM, synchronize it with external database using Asset Import App and publish them in ROQP to pick desired values by end users. About ROQP cons: its visual is a bit different from other portal elements and it's still too slow (waiting 5 seconds for search results without any notice about what's going is everything but not good user experience)