Complex service request with large number of ordered items

[Matt88]

Hi

I'd like to hear from any service catalog workflow developers who have been required to implement a solution which manages tens to hundreds of ordered catalog items per request.

For my current project, I was provided with a high level design which uses service catalog for fulfillment of customer requests which are integrated with ServiceNow using REST API.   The most complex use case will involve an inbound message containing hundreds of services which have been ordered by a customer through a single-page HTML5 application and this order should be managed as one request with each service fulfilled in varying ways, thus requiring independent workflows which may involve integrations with other applications to complete fulfillment.   The design seems reasonable enough as we are dealing with customers requesting services and we can make use of several OOB components to implement a solution.

However, I'm not yet at the point where my solution needs to manage hundreds of items, and I'm already seeing the writing on the wall as the observed performance for submitting a request is slow for just 10 services (~10 seconds as this involves setting up 10 x sc_req_item records which means multiple inserts and lots of business rule operations all running inside one transaction).

I have several avenues to attack this performance problem, such as:

• group alike services together to reduce the number of requested item records
• lump all services into one requested item (as a special type of catalog item) and add the requested items which correspond to each service as an asynchronous operation through workflow after initial submission
• manage the request via one requested item which would require a much more complex catalog item and a very busy workflow whilst providing far less visibility into issues with fulfillment of each requested service

I'm not expecting there will be many with a similar use case to me, but something which would help me immensely is to understand if any customers are currently handling requests of a similar size?   Is there a theoretical limit to the number of requested items which should be associated with a request?   What's the largest anyone has seen?

I'm already well into development of the solution, so I'd be happy to share further insights into what I've built so far.

Regards

Matt

[bernyalvarado · Accepted solution]

Hi Matt,

I have never seen a limit of the items been requested. If all the requests that you will be observing are a bulk of services/products in a single request it does makes sense to engineer your catalog items in accordance to your customer requests. Perhaps you have Kits, Suites that can be requested as a whole.

In regards the performance, it all depends a lot on the logic you have behind the scenes. If your workflows/business rules/events/notifications are properly designed these should be scalable to any size of requests.

Thanks,

Berny

[bernyalvarado]

One final comment... years back we did built a very complex, dynamic set of order guide/catalog items request where there was 1 catalog item workflow that orchestrated the execution of all the rest in accordance to the variable/parameters of the request. The solution worked as a charm and was fully scalable. The key challenge was to later find someone within the customer's pool of resources that could own it to continue building in top of it.

Key learning: When building a new solution, weight the requirement against the complexity of building it and the value that it will provide to the business. When doing so you will find the right balance to develop the right solution in accordance to that critical must have in alignment to what can be afforded by the business.

I hope this makes sense

Thanks,

Berny

[Matt88]

Thanks for the input, Berny!   Your initial reply has given me some confidence about the implementation of individual request items running workflows tied to a parent request.

A challenge I have is extending the solution, building upon it to support new types of requests.   Early on I worked with order guides to understand different ways they could be used, but I went down another path in the end, probably as an order guide implementation did not meet the initial requirements to return a request number and calculated due date at the time the customer's request is posted via REST.   But order guides may provide a way forward, so I will revisit my earlier investigations into their use.