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
Original Message:
Sent: Oct 02, 2022 09:16
From: Paul Stanek
Subject: TMF652 Resource Order Management API - how to create and set relations in one order
Hi,
I have a question about how to use TMF652 to create resources and set up relationships between newly created resources. Let's say we are creating resource A, resource B, and resource C. In addition, we want to set two attributes on resource C - termination1 to the id of resource A and termination2 to the id of resource A. Is it possible to define such an operation as one resource order? Or is there a need for two resource orders - first for resource creation and second for setting relations?
------------------------------
Paul Stanek
Suntech S.A.
------------------------------