Thanks,
@Matthieu Hattab for jumping in!
Yes, the question is indeed generic, especially as a pattern for all TMF Order type API. So if I understand correctly your proposal is to use temporalIds? But for example in Resource Inventory we don't have such attribute on the Resource level (on the level of abstract entity). And how to recognize during relation setting that we are using temporalId? I can only think of using some kind of prefix (like TMPID or something). In this case, my sample would look like this:
{
"name": "Create and set realtions",
"orderItem": [
{
"id": "item1",
"action": "add",
"resource": {
"name": "ResourceA",
"id": "TMPID-ec61167d-150a-4bb6-9225-3a310a0bd86b",
"resourceSpecification": {
"id": "e362d12b54f2",
"href": "host/ResourceCatalog/resourceSpecification/e362d12b54f2",
"name": "ResoruceType-1"
}
}
},
{
"id": "item2",
"action": "add",
"resource": {
"name": "ResourceB",
"id": "TMPID-34544d9d-8f7d-4e67-8769-87b56923b841",
"resourceSpecification": {
"id": "e362d12b54f2",
"href": "host/ResourceCatalog/resourceSpecification/e362d12b54f2",
"name": "ResoruceType-1"
}
}
},
{
"id": "item3",
"action": "add",
"resource": {
"name": "ResourceC",
"termination1": { //ResourceRef
"id": "TMPID-34544d9d-8f7d-4e67-8769-87b56923b841"
},
"termination2": { //ResourceRef
"id": "TMPID-ec61167d-150a-4bb6-9225-3a310a0bd86b"
},
"resourceSpecification": {
"id": "8888888",
"href": "host/ResourceCatalog/resourceSpecification/88888",
"name": "ResourceType-2"
}
}
}
]
}
This will be the best approach for me. But the question is whether this approach is TMF compliant.
------------------------------
Paul Stanek
Suntech S.A.
------------------------------
Original Message:
Sent: Oct 05, 2022 03:41
From: Matthieu Hattab
Subject: TMF652 Resource Order Management API - how to create and set relations in one order
Hi,
Jumping in to understand why I don't see any problem!
I suppose the question is generic and could apply to any API or type of integration.
On the principle that entities in the payload should have unique name. what are the benefit of using temporary Id? A single payload ought to be enough. doing it sequencely with multiple paypload doesn't guaranty each payload was processed correctly (I guess someone could say that with an event driven architecture, each payload successfully processed could broadcast a success message that could trigger the next payload).
What I don't understand is why this is a API "concern". I believe it's only an implementation question: Your server-side code must be designed to read and process the payload correctly and create data in a given order (all resources first, then relationships) so it can resolve foreign key/relationship thanks to unique entity name (and yes, the server-side code could use temp id if that what it takes).
That's how I've seen integration done for decades. For instance, in the old days of CSV "flat" files, the PL/SQL code reads the file, insert data in tables, nice and tidy and resolve foreign keys.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
------------------------------