
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-05-2022 03:43 AM
Hi,
I needed to make changes to a Service Specification (characteristic changes). I created a new version of the existing service specification, made the changes and published it. I retired and archived the previous version. Also updated the decision designer to map the new version to the sub-flow.
Now when I am sending Service Order Open API - Create Order with the new specification id and name as below, getting the "Catalog not found" error. Please help if I am missing something?
POST https://xxxxxxx.service-now.com/api/sn_ind_tmt_orm/serviceorder
Snippet of the request
{
"externalId": "extenal_client_id_123",
"relatedParty": [
{
"@referredType": "Customer",
"@type": "RelatedParty",
"id": "4a3fbea9976411500efbb05e6253afec"
}
],
"requestedStartDate": "2022-03-18T13:36:34.519Z",
"requestedCompletionDate": "2022-04-10T21:25:53.000Z",
"serviceOrderItem": [
{
"id": "rr",
"action": "add",
"service": {
"@type": "RFS",
"serviceSpecification": {
"id": "e43895568796919404e643f9cebb352",
"name": "SDWAN NETWORK SERVICE v2"
},
"serviceCharacteristic": [
{
Response:
{
"code": 23,
"reason": "Missing body field",
"message": "Missing body field",
"details": [
{
"message": "Catalog not found",
"datapath": "/serviceOrderItem[0]/service/serviceSpecification/"
}
]
}
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-26-2022 06:44 AM
Hi @Saurav Paira ,
Irrespective of the number of versions you create; in the payload you should continue to send the base version id (even though it may have been archived). If the version is not explicitly mentioned in the payload, the Application will automatically pick the latest active version.
From your original description, it appears you were passing the v2 sys_id (i.e. incremental version) in the payload.
Copy works because it essentially starts a new branch of the spec as v1.
Can you test & confirm with this approach - send in sys_id of v1 irrespective of your current active version?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-05-2022 12:02 PM - edited ‎10-18-2022 04:45 AM
i believe the challenge you have is that the TMF641 order api works on Customer Facing Services - CFS (not Resource facing Services - RFS). Upon receiving an order line item for a CFS, if the specification defines that RFS is required, the RFS domain orderis created but you cannot start with a service order line item referencing an RFS.
<<Updated - this was incorrect guidance - the Service Order API does work with either CFS and RFS elements>>

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-05-2022 01:18 PM
Thanks Tom for your quick reply. But it was working until I created a new version of the Service Specification. I created the new version by clicking on the "Create New Version" button.
Now we tried to create a new Service Specification using "Copy" and that copied service specification is also working. Not sure whats the issue with "Create New Version".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-17-2022 03:43 AM
Hi @Saurav Paira , have you tried passing "internalVersion": "x" (where x is your current version corresponding to the spec id you are passing)?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-24-2022 05:47 AM
Hi @ShashankInamdar yes keeping the id value to the version 1 of the spec's sys_id and internalVersion 2, seems to work. If we change the id to the sys_id of the version 2, then it fails to find. This sys_id of the version 2 was confusing.