Cisco Cisco Evolved Programmable Network Manager 2.0 Developer's Guide

  

 

 

Cisco EPN Manager 2.0.3 RESTCONF NBI Guide  

 

 

245 

 

When a call to provision a service is made, it is not possible to guarantee a timely response 
- this may be dependent on the load on the system currently among other factors. Due to 
this uncertainty, the Cisco EPN Manager server, upon receiving a request to provision a 
service, sends out a response to the user immediately after submitting the task for 
provisioning. The actual completion/ failure status of the provisioning task is sent out as a 
notification to the subscribed clients.  
 
The response obtained by the client is expected to contain the following information: 

  The Service ID - a unique ID that was created for that particular request. Audit trails 

for this task can be done using this ID. 

  The name of the service that was submitted 
  The type of deploy-action (Preview or Deploy) 
  The type of the operation (Provision, Modify, Terminate) 
  The status of the operation (SUBMITTED if successfully submitted, FAILED 

otherwise) 

  A generic notification URL (for connection-oriented notifications only) - to receive 

notifications on the status of any provisioning task. This URL is predefined and can 
be subscribed to even before submitting the provisioning task 

o  URL: 

https://<epnm-server-fully-qualified-domain-

name>/restconf/streams/v1/service-activation[.xml | .json]

 

  where appending the url with .xml will result in notifications 

serialized to xml and .json will result in notifications serialized to json 

o  Authentication: Basic auth 

  A request-specific notification URL (for connection-oriented notifications only) - to 

receive notifications on the status of the current request only - this is identified by 
the service-id 

o  URL: 

https://<epnm-server-fully-qualified-domain-

name>/restconf/streams/v1/service-activation/<unique-service-id-
obtained-in-response>

 

o  Authentication: Basic auth 

 
For connectionless notifications, the workflow of subscribing and receiving notifications is 
the same as that of inventory notifications, except the "topic" has to be "service-
activation". The same endpoint that receives inventory notifications may be used to 
receive service-activation notifications. 
 
A sample client for subscribing and listening to connection-oriented notifications is 
provided in the next section. Connectionless notifications can be received by any REST 
service accepting an XML or JSON payload via a POST request.