Open APIs

 View Only
  • 1.  APIs for allocating work request to partners supplying engineering services

    TM Forum Member
    Posted Jan 21, 2022 05:55
    Hi,

    We are investigating the modernisation of our existing IT used to send work requests to partners who we have contracts with to supply resource to complete civil engineering work (network build, roadworks, tree cutting services etc) and at the moment the emphasis seems to be on B2C/B2B - which is completely reasonable - but has there been any thought about these kind of services? If we are ahead of some others I'd be happy to share our work and collaborate with others on the definition of the APIs.

    ------------------------------
    Steve Ranford-Bragg
    BT Group plc
    ------------------------------


  • 2.  RE: APIs for allocating work request to partners supplying engineering services

    TM Forum Member
    Posted Jan 21, 2022 07:00
    Looking into the ABE's which might be used here, there seem to be two related ones. We are procuring a service from a supplier and so there are elements on issuing an order, invoicing and bill payment but what we're issuing is more akin to a work order as it is requesting stuff to be done rather than the delivery of a service or asset. Possibly there could be an association between the two to allow for the procurement of either goods and also completion of work orders by a supplier?

    ------------------------------
    Steve Ranford-Bragg
    BT Group plc
    ------------------------------



  • 3.  RE: APIs for allocating work request to partners supplying engineering services

    TM Forum Member
    Posted Jan 23, 2022 04:54
    Hi Steve
    Some of the ODA use cases are looking at soliciting services from third parties, and have been discussions around a purchase order component to mediate this. @Ludovic Robert and @Sylvie Demarest could probably give more information.
    Specifically regarding work order - there is a suite of work-related APIs in early development in the Open API project. I think that a main challenge here will be - for the consumer of (say) a Work Order API (e.g. BT), how do you "know" what is in your suppliers' "work catalog" so that you can correctly construct the work order.
    Very interesting discussion point that you have raised here.​​

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 4.  RE: APIs for allocating work request to partners supplying engineering services

    TM Forum Member
    Posted Jan 23, 2022 06:25
    Edited by Steve Ranford-Bragg Jan 23, 2022 11:09
    Yes, this is a bit of a different case to a standard procurement process where you're buying from a supplier. In this use case the work orders are being placed on the basis of a defined contract with our partners and prices so we actually dictate the catalogue and the specification of what is being provided by the supplier.
    We also place work requests to third parties based on contracts to do things like provision of orders to give us more flex in our field engineering resources so there would feel like several possible use cases for this - I'd imagine other large network and service providers may also have a similar requirement? I'm going to involve @Tony Shepherd to help with the process view of this too when he returns from leave.


    ------------------------------
    Steve Ranford-Bragg
    BT Group plc
    ------------------------------



  • 5.  RE: APIs for allocating work request to partners supplying engineering services

    TM Forum Member
    Posted Jan 26, 2022 06:53
    Edited by Steve Ranford-Bragg Jan 26, 2022 10:58
    Having given this some more thought, there was a danger of trying to overcomplicate it and end up trying to replicate the level of the OASIS standards for ebXML which I think goes too far. However, there is value I think in providing a method of managing work orders with another party that gives the important parts of ebXML for reliability and non-repudiation until there is a decision on how it should be managed and included in the TMF standards.

    What I'm considering uses existing APIs and consists of:

    1.  The work specifications are published by the entity catalogue management API which defines a set of work items with units, characteristics, prices etc so they are machine readable for publication of new contracts and versions etc.

    2. The work order API will be exposed by the work originator (in this case Openreach) to manage the tasks. Openreach applications will be able to create a work order and then both Openreach and the third party will be able to use the GET/PUT/PATCH/DELETE operations to manage updates and transition the work order as it progresses.

    3. The event management API will be used to allow third parties to be notified of work being allocated to them by subscribing to a topic and then Openreach creating an event for that topic. Work order details will be sent in the work order create event.

    4. The delivery receipts in ebXML will be replaced with an HTTP header with a correlation id that denotes that the message has been received and persisted for processing. For example on receiving the work order create event, the third party will update call the API to update the state to "acknowledged" and pass an input header with their correlation id that signifies it has been persisted on arrival. The response to the update will contain a correlation id that the request has been persisted before being actioned.

    5. To add the non-repudiation offered by ebXML, key pairs will be generated and the private key used to sign part or all of the message payload. The public key will be shared with the other party who can then decrypt the payload to authenticate that the incoming message is from the expected origin.



      ------------------------------
      Steve Ranford-Bragg
      BT Group plc
      ------------------------------



    1. 6.  RE: APIs for allocating work request to partners supplying engineering services

      Posted Jan 27, 2022 11:45
      Steve

      I think this addition to the thread is a bit of a non-sequitur to the previous one?

      Prior to this you were discussing information models for an envisaged API?

      This latest message in part  now attempts to deal with with Integrity/Non-Repudiation requirements for an API together with the reliable asynchronous delivery of information. 

      On the second of these I would caution  trying to extemporise on how to  realise these risk mitigations on a single API. But I note that the Open API team seem to have left these wider concerns open for implementers to resolve for themselves?

      Trying to select technologies, and define their usage, to cover the whole of the C.I.A security requirements for both information in motion and at rest and achieve idempotency of asynch messaging and ensure that is compatible with the security standards supported in the OpenAPI specification standards could become a tall order.

      Moreover these features will then become an issue for achieving interoperability with other partners in a B2B model. 

      Ideally you would want to solve these issues once for a variety of APIs and in concert with others implementing similar solutions.

      For example I get the impression that you have chosen to regard digital signing as a means of dealing with authentication of the origin? Infact technologies like XMLDSIG, JWS, HMAC and the like are as much about message integrity as anything else. Moreover these technologies have to be clear on issues like the relationship between encryption and signing, and which bits of a message are signed (due to issues of transformation of http headers and the like in flight), and the PKI infrastructure (or not) behind them.

      You mention ebXML. Well the approach taken there was to conduct an initial risk assessment and look at compatible technologies to address those  risks (url below)

      http://www.ebxml.org/specs/secRISK_print.pdf 

      Moreover the technologies were chosen to be compatible with one another. And great pain was taken to ensure be clear what it was about a message which was signed (whether it would include timestamps for example) and also to be clear that it was a signature of the message as created, sent, received and persisted in a message store without being transformed and /or stored in a business system of record. 

      Oh and not only was it standardised and tested for interoperability of various implementations, it was also defined to be configurable on a partner by partner basis and not baked into the API of the internal systems.





      ------------------------------
      Derrick Evans
      ------------------------------



    2. 7.  RE: APIs for allocating work request to partners supplying engineering services

      TM Forum Member
      Posted Jan 28, 2022 04:50
      Hi Derrick,

      Sorry yes, it was a bit of a segway but having decided that rather than trying to create something new we could re-use an existing API to manage a solution there where still the other issues based on concerns raised by the suppliers around the potential move away from ebXML. I completely agree with you it's not the right solution long term but would possibly address the concerns around the transformation away from ebXML,  however there needs to be a standard which allow interoperability and agreement across the TMF platform.

      At the moment someone running a solution for ordering a SIM or a consumer broadband service is probably not going to be so concerned about these kinds of things but as it moves up the value chain to things like a large optical solution solution where the costs can run into hundreds of thousands of pounds and have very long life spans for fulfilment or running a B2B marketplace it will become much more important.

      Co-incidentally I had a call with George Glass to discuss our implementation of the TMF APIs and we discussed this and he is going to ask the team to look at how it might be brought into the standards.

      ------------------------------
      Steve Ranford-Bragg
      BT Group plc
      ------------------------------