Search the Community
Showing results for tags 'spawn'.
We are just testing implementing a LogIncident and LogServiceRequest API calls. These are api calls are successful and the results returns the RequestId, summary and an empty warning array. We are including the ServiceId and CatalogId in the requests which is showing correctly when we view the request in the live user application. However a linked BPM process is not being spawned when to make these requests, even though the documentation states it will be when the providing the ServiceId. We have also tried the LogRequestBPM node afterwards but this returns the 'defaultProcessNotSet'. We do not set a default BPM process at the Service Level as we have the system set to enforce the selection of the catalog. I wondering if the api documentation needs to be updated when using the combination of ServiceId and CatalogId? We are not passing a bpmName, as we are expecting the provision of the ServiceId and CatalogId to used to determine this rather than having to hard code this or make an earlier call to get the bpmname from the service details. Cheers Martyn
As confirmed under linked post below. the current API log request nodes only spawns a BPM if you specify the the serviceId and have a default BPM set at the service level. With the development of the service catalog and catalog items are now available on all current request types to allow use of different BPM workflows, can the API call logic be enhanced to apply the same capability that it offers for 'Service' level requests, so that the catalog specific BPM workflow is spawned when passing both the serviceId and catalogId as parameters. At the moment you have to undertake an additional request first of to obtain the current BPM name from the catalog before being able to call the Log api endpoint as you need to pass the BPM Name, which is not efficient. Similarly you would not want to hard code the BPM Name in your application. Cheers Martyn