OUTLINE:
Whitepaper:
Service Level Agreements Using Hyperledger Fabric
Purpose of This Paper
The purpose of this paper is to describe and build a Service Level Agreement (SLA) prototype on Hyperledger Fabric using Composer while using existing software components as much as possible.
Our participants will leverage knowledge gathered during earlier collaborative projects to be able to deliver effectively and to not reinvent the wheel.
Intended Audience
Our intended audience is CIO's, CDO's, CTO's and Developers working in organizations whose performance is dependent on meeting Service Level Agreements both internally and externally. Our proposed solution will adhere to the Service Provider - Vendor model but can also be aligned to other technical service management models like those described in the ITIL methodology.
1. Introduction
A service level agreement (SLA) quantifies the details of a business contract between two business entities (in our case a service provider and a service vendor). These details include the minimum quality of the service provided, service uptime commitments (reliability) and technical support availability (responsiveness). Depending on the nature of them (internal, external etc.), the breach of SLAs could have legal consequences for the breaching party.
The steps of an SLA can be introduced as follow:
1- Negotiation and agreement: An essential step to agree on an SLA is quantifying the service levels using performance metrics. For instance the in ISP/Customer SLAs, the service uptime is typically provided by a percentage e.g., 99.999%.
The other vital part of an SLA is the clear description of the consequences of the breach of contract for the parties involved e.g., penalties, compensations etc.
2- Enforcement: The perfect SLA, if not accompanied by an efficient enforcement tool, would not satisfy the parties involved. The enforcement of the SLAs has many challenges:
a- Different interpretations of the SLA
b- Different measurements of the performance metrics (especially the metrics such as latency which are not very straightforward to measure)
c- Manual monitoring of the SLA parameters at all times.
d- SLA violation detection
Both of the above-mentioned steps to assure the operation of an SLA are currently done manually between the telecos.
1.1 SLA Record-keeping
The distributed ledger technology built into the Hyperledger projects can bring trust to the record-keeping process in SLA monitoring and management. In other words, the measurements of the quality parameters along with the SLA violation incidents can be kept as immutable records in the distributed ledger.
1.2 SLA Enforcement
Smart Contracts could benefit greatly from the smart contract technology through automation of the enforcement process. For instance, a chaincode can define a set of SLA violations and their subsequent penalties (this could be done through a financial transaction built into the chaincode) therefore automating the enforcement process and bypassing the manual process of the SLA enforcement.
2. The Blockchain Framework
We use Hyperledger Composer to implement the proof of concept application of SLA Management over the blockchain. The reason behind this choice is:
a- Simplicity of writing chaincodes using Hyperledger Composer
b- Hassle-free application development without worrying about the deployment details of the blockchain network.
c- Hyperledger Composer's features such as the REST API and the Angular APP
3. The Business Network
This business network consists of the following components:
Roles:
Originator
ServiceProvider
Vendor
enum Role { o Originator o ServiceProvider o Vendor }
Participants:
ServiceProvider
ServiceVendor
Customer
participant ServiceProvider identified by providerId { o String providerId o String name } participant ServiceVendor identified by vendorId { o String vendorId o String name } participant Customer identified by custId { o String custId o String name }
Assets:
TroubleTicket
asset TroubleTicket identified by incidentId { o String incidentId o String vendorTicketId optional o String type o Severity severity o String description o DateTime creationDate o String status o DateTime acknowledgedDate optional o DateTime resolutionDate optional o DateTime targetAcceptedTimestamp optional o DateTime targetClosedTimestamp optional o String acceptanceSLA optional o String closureSLA optional o Note[] note optional -->ServiceProvider SP -->ServiceVendor SV optional -->Customer C }
Transactions:
CreateTicket
AssignVendor
UpdateTicket
ResolveTicket
CloseTicket
transaction CreateTicket{ --> Customer C --> ServiceProvider SP --> ServiceVendor SV o String incidentId o String type o Severity severity o String description o DateTime creationDate o String status } transaction AssignVendor{ --> TroubleTicket ticket -->ServiceVendor SV o String status o DateTime statusChangeDate o String statusChangeReason } transaction UpdateTicket{ --> TroubleTicket ticket o String status o DateTime statusChangeDate o String statusChangeReason } transaction ResolveTicket{ --> TroubleTicket ticket o String status o DateTime resolutionDate o String statusChangeReason } transaction CloseTicket{ --> TroubleTicket ticket o String status o DateTime statusChangeDate o String statusChangeReason }
Testing:
To test this Business Network Definition in the Test tab on the playground or in your Angular app:
1- In the Customer
, ServiceProvider
, ServiceVendor
participant registry, create new participants with appropriate input values.
Alternatively, you can also use the SetupDemo
tranaction which would populate the network with 2xCustomers, 2xServiceProviders, 2xServiceVendors.
2- Creat a ticket using the Submit Transaction
button and fill in the information based on the created participants. Upon submission, you should see a new asset added to the asset lists under 'TroubleTicket'.
4. SLA Back & Front-End
The following figure shows the Participants in the app and the process of creating them.
The following figure shows the Transactions in the app and the process of invoking them.
OLD Content
This section describes an earlier application interface for the SLA solution including prints of the service provider -and vendor screens.
Back-end on Bluemix (Demo Transaction) :
Front-end interface:
Green = Service Provider screen
Purple = Vendor screen
Item 1
Item 2
Item 3
2.1 Ticket creation - service provider
From the provider screen, click 'Create'
2.2 Enter details and save
Enter the ticket details and click 'Save'
2.3 View created ticket
The ticket is created and the details are displayed. Note that the SLA details have been calculated by the blockchain.
2.4 Go back to List view
Vendor view
The Vendor views are displayed below
4.1 Refresh list to see new ticket
4.2 View the ticket
The details have been read from the blockchain
4.3 Accepting vendor ticket
Update the ticket by changing the status to Acknowledged, entering a comment and saving the ticket
Tickets appearing in service provider view
The following screens show the consequent service provider view
5.1 Notification on the service provider ticket
A notification appears indicating that the ticket has been updated
5.3 view the updated service provider ticket
Click on 'show' to see the update and the ticket has been set to acknowledged, and the Acceptance SLA has been calculated - in this case it has failed.
5.4 Vendor Updates
Going back to the Vendor view, we can resolve the ticket and set a comment and save
Note that the closure SLA is also being calculated
5.5 Service Provider move back in progress
On the service provider side you can close the ticket or put it back in progress
If you put it back in progress, the closure SLA status is cleared. You can then resolve the ticket in the vendor system.
Conclusions
This white paper explained... [sum up the white paper briefly. This section “tells them what you told them.” Although this may seem repetitive, some people flip to the back of a document to see “the bottom line” and what they might have missed.]
Further Resources
[In this section, list any further resources or interesting reading that might illuminate the topic more. Include enough detail so that a reader could easily locate that source, including URLs if appropriate.]
Notes
[Although GDocs can’t do Endnotes, the designer will move all your footnotes here. In every footnote, provide the AUTHOR(s), the article or document TITLE, the PUBLISHER, the DATE, and if you have it, the PAGE NUMBER. For a website, include the URL and RETRIEVED ON DATE.]
POINTS TO COVER
- Motivation / Problem
- Barriers
- Customer Groups
- Opportunities
Solution:
Platform
Team
Road map- Mission
- Use Cases
- Conclusion
This work is licensed under a Creative Commons Attribution 4.0 International License
creativecommons.org/licenses/by/4.0
Acknowledgements
[list all the contributors to the white paper in alphabetical order by LAST name. Many working groups keep a list of members or contributors on their wiki pages or their minutes. Don’t include anyone’s name without their okay.]
Whitepaper Standards Contributed by Learning Materials Development Working Group, Gordon Graham and Bobbi Muscara