Open APIs

I notice in the latest release of the TMF640 API (18.5.0) that all reference to asynchronous requests has been removed. Does this mean there is no support for asynchronous activation requests, an alternative to 640 for asynch is available or this is just an oversight in the latest 640 version? Why does the document still reference Monitors?

------------------------------
Stuart Batten
Telstra Corporation
------------------------------

Hi Stuart

I think we handled this in our offline discussion, but for the benefit of the wider community I will clarify that this is a defect and we need to issue a fix for TMF640 to allow return of HTTP code 202 (Pending) for POST (and PATCH) operations.

We would be pleased to hear from community members if they think any other APIs need this asynchronous response capability.
Note that many APIs support asynchronous behavior using TASK resources, where creating (POSTing) the task creates a task resource synchronously and the task starts running. So if this fix is needed it will be only for operations on managed resources (e.g. Service in TMF640 Activation and Configuration).

------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------

Hi Jonathan, 

Sorry for being hijack this thread. 
we also trying to using TMF640 expose as asynchronous request where by in backend doing  orchestration. 
for the aync acknowledge response, is that we can customize the response instead of the "Service" object?

------------------------------
Chio Chuan Ooi
SingTel Optus
------------------------------

Original Message:
Sent: May 23, 2019 07:45
From: Jonathan Goldberg
Subject: TMF640 asynchronous requests

Hi Stuart

I think we handled this in our offline discussion, but for the benefit of the wider community I will clarify that this is a defect and we need to issue a fix for TMF640 to allow return of HTTP code 202 (Pending) for POST (and PATCH) operations.

We would be pleased to hear from community members if they think any other APIs need this asynchronous response capability.
Note that many APIs support asynchronous behavior using TASK resources, where creating (POSTing) the task creates a task resource synchronously and the task starts running. So if this fix is needed it will be only for operations on managed resources (e.g. Service in TMF640 Activation and Configuration).

------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------

Hello Chio Chuan

Did you assessed capability to manage this async with the monitor resource ? then if it is more complex to orchestrate you can also assess use of TMF 641 service ordering. All depends of these customizations that you want to introduce on your service resource.

Hope it helps

Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------

Original Message:
Sent: Apr 28, 2020 22:50
From: Chio Chuan Ooi
Subject: TMF640 asynchronous requests

Hi Jonathan,

Sorry for being hijack this thread.
we also trying to using TMF640 expose as asynchronous request where by in backend doing  orchestration.
for the aync acknowledge response, is that we can customize the response instead of the "Service" object?

------------------------------
Chio Chuan Ooi
SingTel Optus
------------------------------


Original Message:
Sent: May 23, 2019 07:45
From: Jonathan Goldberg
Subject: TMF640 asynchronous requests

Hi Stuart

I think we handled this in our offline discussion, but for the benefit of the wider community I will clarify that this is a defect and we need to issue a fix for TMF640 to allow return of HTTP code 202 (Pending) for POST (and PATCH) operations.

We would be pleased to hear from community members if they think any other APIs need this asynchronous response capability.
Note that many APIs support asynchronous behavior using TASK resources, where creating (POSTing) the task creates a task resource synchronously and the task starts running. So if this fix is needed it will be only for operations on managed resources (e.g. Service in TMF640 Activation and Configuration).

------------------------------
Jonathan Goldberg
Amdocs Management Limited

Hi Ludovic, 

Thanks for reply. 
Yes, we do explore that, but based on my understand that TMF641 is the service ordering which is doing the order decomposition.
As we just want to expose the API purely for activation and not intend to do the order decomposition as our consumer already doing service order management. 

Thanks. 

Regards,



------------------------------
Chio Chuan Ooi
SingTel Optus
------------------------------

Original Message:
Sent: Apr 30, 2020 03:34
From: Ludovic Robert
Subject: TMF640 asynchronous requests

Hello Chio Chuan

Did you assessed capability to manage this async with the monitor resource ? then if it is more complex to orchestrate you can also assess use of TMF 641 service ordering. All depends of these customizations that you want to introduce on your service resource.

Hope it helps

Ludovic

------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------


Original Message:
Sent: Apr 28, 2020 22:50
From: Chio Chuan Ooi
Subject: TMF640 asynchronous requests

Hi Jonathan,

Sorry for being hijack this thread.
we also trying to using TMF640 expose as asynchronous request where by in backend doing  orchestration.
for the aync acknowledge response, is that we can customize the response instead of the "Service" object?

------------------------------
Chio Chuan Ooi
SingTel Optus


Original Message:
Sent: May 23, 2019 07:45
From: Jonathan Goldberg
Subject: TMF640 asynchronous requests

Hi Stuart

I think we handled this in our offline discussion, but for the benefit of the wider community I will clarify that this is a defect and we need to issue a fix for TMF640 to allow return of HTTP code 202 (Pending) for POST (and PATCH) operations.

We would be pleased to hear from community members if they think any other APIs need this asynchronous response capability.
Note that many APIs support asynchronous behavior using TASK resources, where creating (POSTing) the task creates a task resource synchronously and the task starts running. So if this fix is needed it will be only for operations on managed resources (e.g. Service in TMF640 Activation and Configuration).

------------------------------
Jonathan Goldberg
Amdocs Management Limited

Hi Jonathan,

Any reason why asynchronous DELETE would not be permitted? A resource that needs asynchronous behavior for POST or PATCH might also need this for DELETE operations.

Best regards,

------------------------------
Roland Leners
alvatross by SATEC
------------------------------

Original Message:
Sent: May 23, 2019 07:45
From: Jonathan Goldberg
Subject: TMF640 asynchronous requests

Hi Stuart

I think we handled this in our offline discussion, but for the benefit of the wider community I will clarify that this is a defect and we need to issue a fix for TMF640 to allow return of HTTP code 202 (Pending) for POST (and PATCH) operations.

We would be pleased to hear from community members if they think any other APIs need this asynchronous response capability.
Note that many APIs support asynchronous behavior using TASK resources, where creating (POSTing) the task creates a task resource synchronously and the task starts running. So if this fix is needed it will be only for operations on managed resources (e.g. Service in TMF640 Activation and Configuration).

------------------------------
Jonathan Goldberg
Amdocs Management Limited
------------------------------