I would have the REST API create CIs in its own dataset. What is the ID being used to create the CI? It would seem you could use the submitter within the specific dataset to get the entry.
Which REST API are you using for creating CI? Apparently you mentioned the version you are using is 'Remedy 9.1'.
If you use API "/api/cmdb/v1.0/instances/<dataset_id>/<namespace>/<class_name>" for creating CIs then it returns the instance ids response. The instance id can be supplied to another REST API "/api/cmdb/v1.0/instances/<dataset_id>/<namespace>/<class_name>/<instance_id>" for fetching the details of that CI.
If you can confirm exact version you are on, I can confirm whether above mentioned APIs be available or not.
I hope it address your use case.
There is an account we will be using for all REST API calls, so not sure it's really a good way to search for a recently created CI, since all CIs will have been created by this account. The account is used by a web service so there may be multiple CIs being created within second by the same account.
CMDB REST API is not installed, so I'm only able to use the AR REST API.
Were you planning to create CIs in BMC.CORE:BMC_BaseElement? By default, attribute with Field ID = 1 (RequestId) is returned upon successful creation of record in this (or any other) form; this can be altered, if necessary (e. g. InstanceId is unique among all CIs and all of their instances in all datasets). On top of that, you could query before posting new CI, or use merging configured to always create new record.
Did you consider creating record in AST:Attributes as well?
Please help me with the release/version you are on?
We are creating CIs in the AST forms because we need to populate the non-BMC CORE fields such as AssetLifecycleStatus without needing an extra REST API call (to populate the AST:Attributes form). I would love to get back either the ReconciliationIdentity or the InstanceId of the CI that was created.
Remedy 9.1 is as much as I know.
You should be able to get Reconciliation Identity or any other attribute in response if you specify which attributes you wish to be included there by listing them in qualification parameter fields=values(<attribute #1>, <attribute #2>,... <attriibute #n>) so try
POST <protocol>://<server>:<port>/api/arsys/v1/entry/<AST form>?fields=values(Reconciliation Identity)
to get something like
Thanks, I've tried that and I don't get any response body back, and get a 204 response code.
2 of 2 people found this helpful
That sounded strange, but then I had a look at documentation and found this note:
Display-only forms and Join forms do not generate an entry ID
when they are created, and the status code 204 is returned. If an
entry ID is generated, such as on a regular form, status code 201
with the Location header is returned. When Display-only forms and
Join forms are created, field parameters are not honored.
Can your web service generate its own UID, to be populated in dedicated field in one of or both underlying regular forms, and include it in transaction? That way you'd still need only one transaction to create CI and HTTP Status 204 would indicate that CI with particular UID created by web service had been created in CMDB; if necessary, you could also query on that external UID from CMDB/Remedy as well.
There's the answer I guess.
I thought about populating the tokenId field with a UID I generate but that doesn't actually save me any steps, but would guarantee I find the right CI. However, as my web services doesn't have a corresponding CI so UID in this case is not technically a foreign key so doesn' tmeet the deifnition we have for TokenID. I could go back and delete it after I get the ReconID but that sounds like a lot more work considering the risk of getting the wrong CI using Name ordered by create date.
I don't see any other obvious answer, so I guess I;m kind of out of luck. At least I understand why and the options I have.
Thanks for your help.
Thank you, it seems we've both learned not what we hoped, but at least something from your question. (In case it was unclear, I was proposing additional key which would be used instead of token ID or anything else normally used to identify CIs during integration, normalization, reconciliation or beyond.)
Also, if you don't mind moving some workload to AR server, you could have your web service not directly transact with AST form, but instead have it transact with custom regular staging form with some workflow attached to it which would "promote" data into AST form and return all necessary values back to your web service.