OUTLINE: 

Whitepaper:

Service Level Agreements Self-Assessment with Hyperledger Fabric

Purpose of This Paper

The purpose of this paper is to define a framework prototype for Service Level Agreements (SLAs) Self-Assessment on Hyperledger Fabric. The proposed approach incorporates SLA Self-Assessment on Hyperledger Fabric using Trusted Execution Environments (TEEs).
Knowledge gathered during earlier collaborative projects is leveraged, such as Fabric Private Chaincode[1].

Intended Audience

The intended audience comprises of various organization representatives, their developers, and their clientele, contracting with different SLA types. The proposed approach aims to cover dissimilar types of SLAs through a generic approach model where the requested actors' roles (e.g. service provider, service vendor, service seller, application provider, application client, customer, end-user, etc.) and contract activity are defined and addressed completely inside the dedicated framework.

1. Introduction

Service Level Agreement (SLA)

A Service Level Agreement (SLA) defines the promised service(s) of a business interrelationship between two (2) actor entities. A promised service is offered by the actor that provides the service (i.e. the provider actor) to their customer that receives it (i.e. the client actor) . Particular parameters and metrics of such promised services include service availability, minimum Quality of Service (QoS), service up-time commitments (i.e. reliability), technical support responsiveness, and others. In case that the promised service metrics of a provider actor do not match to the actually offered service metrics of the respective customer actor (i.e. the receiver of the service), one or more SLA violations occur. SLA violations lead to possibly legal consequences for the actor entity that provides them. The presented approach  adopts appropriate refund mechanisms that are deployed on the blockchain network and triggered on the occurrence of such violations.

SLA Monitoring and Computation

An SLA Monitoring process requires specific questions to be addressed, as depicted in Figure 1:

• Which are the parameters contained in the SLA?

• How are the SLA parameters computed?

• Is the computation of the SLA parameters in line with the corresponding SLA definition of the provider actor?

In order to validly monitor an SLA, the definition of the SLA parameters' values consists of crucial points that acknowledge an SLA as violated, and of the ways through which the parameters' values are computed. The respective metrics computation is fully dependent on factors such as the sampling rate, the period of evaluation and the dedicated formula that calculates the parameters.

Figure 1: Standard SLA Monitoring process

SLA Self-Assessment

Envisioning the concept of SLA self-assessment, this whitepaper aims to present a securely computational privacy environment where the deployed agreements are monitored with their metrics computed inside the immutable ecosystem.

In the presented solution, the provider actor is able to propose different parameter fields that state an SLA definition with its parametric values. At the same time, the client actor engages confidently in a secure ecosystem where their metric data related to services consumption and utilization are characterized by integrity and precision. Computational transparency and privacy of the metric data are assured through the dedicated computational workflow that adopts related TEE properties. As the entire SLA intelligence unfolds within TEE-deployed smart contracts, the isolated and protected monitoring and computation of the SLA metric data are ensured. The presented framework prototype allows for the independent assessment of SLAs with metric rules that are agreed preceding the contract commitment. 

2. Existing Solutions

The presented solution addresses all the necessary SLA assessment questions through a complete ecosystem that relies on transparency and privacy. However, relevant scientific research aims to solve important problems in neighboring scientific areas without addressing the entire domain as a whole problem. 

1. Nguyen et al. [2] present an evaluating and enforcing architecture for SLA agreements based on distributed ledgers. Their approach relies on keeping the SLA assessment procedure safe and unmodified due to blockchain immutability while utilizing an automated SLA monitoring and computation process that takes place within the blockchain infrastructure and guarantees the successful completion of the SLA evaluation with status acknowledgment for the end-user. However, their solution does not perceive the system in a whole decentralization model, neglecting the possibilities for fairer agreements in terms of transparency and privacy. 
   
   Similar approaches are bounded by the same kind of models where the SLA intelligence lacks a holistic view, while privacy and transparency issues should be tackled. Ranchal and Choudhury [3] present an autonomous and trusted framework for unceasing SLA monitoring in multi-cloud ecosystems. In order to fairly detect SLA violations in a hierarchical system structure, their solution is aiming to address the SLA assessment procedure in a multilevel cloud environment with diverse regulations and laws. Furthermore, Alowayed et al. [4] propose a provider evaluation solution according to the providers’ commitments to their interconnection SLA agreements. Through a metric measurement mechanism the SLA scores are verified for each provider towards their on chain evaluation. By endorsing a privacy-preserving protocol for SLA agreements, it is pursued to objectively define the provider's SLA score and privately store it on chain in order for the interested end-user to access.
   
   
2. Other approaches suggest more focused solutions as far as the privacy of the blockchain participants is concerned, however, they still do not tackle entirely the on chain privacy of the user data from third blockchain parties. Uriarte et al. [5] present an SLA management framework that resolves the specification and enforcement of dynamic SLAs that track and define the service parameter which render SLAs changes over time. The proposed architecture manages to convert an SLA to its smart contract equivalent that dynamically unfolds service provisioning and sequentially generates objective measurements for the SLA assessment through a federation of monitoring entities. In similar research, Alzubaidi et al. [6] proposed on chain assessing SLA compliance and consequences enforcement through dependability validation. By employing a diagnostic accuracy method, trust is assumed in service providers in order to acknowledge SLA breach incidents and execute the corresponding compensations. 
   
   
3. Finally, other approaches try to address the related research area, however, they lack the kind of simplicity and utility in the system's workflow as far as the actor users participation is concerned. D’Angelo et al. [7] inspect the challenges for enforcing accountability in Cloud infrastructures where SLA violations form an important and usual circumstance while arguing that blockchains seem to establish a key contributor towards accountable Clouds. Also, Tan et al. [8] propose a novel performing and safe SLA model where the trust among the different actors are addressed through blockchain. There is a clear argument on lack of effective supervision for the third-parties that manage the monitoring and lack of efficient compensation mechanism on SLA violations. The presented model supervises the provider actors on the blockchain with dedicated smart contracts.

Table 1: A comparison of research literature and SLA Self-Assessment

In Table 1, a comparative assessment of the SLA Self-Assessment approach and the research literature in relevant scientific areas is showcased. For every neighboring research area, the SLA Self-Assessment solution includes at least the respective properties as displayed in the corresponding column. For further deep dive into the various approaches, please use the References section.

3. Architectural Approach of Blockchain SLA Self-Assessment

As more enterprises are deploying innovative blockchain solutions, there exists a greater requirement for trust in transactional activities inside permissioned networks. The SLA operational intelligence is carried out within secure barriers that permit computational transparency and privacy inside these settings in the context of SLA self-assessment. 

The most significant quality attributes of an SLA Self-Assessment approach are detailed in this whitepaper using an SLA Trusted Monitoring process. Envisioning the coverage of various SLA types and agreement cases, the presented SLA Trusted Monitoring is providing SLA computational justice. On the one hand, the infrastructure provider involves their customers in a secure system that permits both computational transparency and privacy at the same time. The former attribute is primarily a result of the widespread on-chain agreement over the selected SLA evaluation methods utilized to monitor the SLA logs, whereas the computational privacy is established by the corresponding traits and capabilities of the on-chain TEE [9]. On the other hand, a secure platform that ensures the reliability of SLA Self-Assessment benefits the customer. The customer is ensured that the offered SLA computations originate from a certain calculation scheme that was decided upon at the outset of their contact with the infrastructure provider. Furthermore, the SLA Trusted Monitoring process as a whole unfolds within a permissioned blockchain network that makes use of the advantages of Distributed Ledger Technologies (DLTs) outfitted with on-chain TEEs. The system is specifically built on the Hyperledger Fabric distributed ledger software [10], which supports an dedicated on-chain TEE by utilizing the appropriate dedicated enabler, namely the Hyperledger Fabric Private Chaincode (FPC) [11]. The latter offers an extension to the on-chain framework that enables the creation and deployment of protected, isolated environments for the execution of smart contracts.

Figure 2: Blockchain SLA Self-Assessment Architecture

The ecosystem of the solution that specifies SLA Self-Assessment under the umbrella of transparency and privacy of operations is shown holistically in Figure 2. The ecosystem's standardized process, which largely consists of the on-chain scheme combined with the explicit off-chain contacts, is leveraged by the provider actor and the client actor. A brief and general description of the process and its interactions follows.

The architectural platform is based on a permissioned blockchain network with each of its two main actors being a blockchain participant. The Agreement Payment takes place as a transaction between the interested parties when a client actor purchases an SLA product offered by the provider actor. The Agreement Payment is a blockchain transaction that contains the appropriate product purchase and is validated by the signatures of the interested parties. The agreed-upon Parametric SLA template digital document is signed by both parties throughout this process, and the on-chain TEE is informed that a dedicated Parametric SLA has been signed. The Parametric SLA Signed includes the required SLA data specified by the Agreement Payment as well as verification of the actor entities participation in the form of the corresponding digital signatures. The TEE sequentially adds the Parametric SLA Signed as a new agreement to its registry of SLA Self-Assessments, where it continuously offers the specialized and enclaved operations services. The Enclaved Monitoring, which gets the SLA metrics from the Tunneling Shim, supports constantly the TEE. The latter acts as an enabler for Cloud Logger and InterPlanetary File System (IPFS) connectivity while controlling securely the external integration points of the blockchain network. The TEE also supports the Enclaved Comparison component, which computes SLA violations on its behalf and initiates the Refund Chaincode, when the necessary conditions are satisfied. Eventually, the latter is activated in the event of violations, and satisfies and compensates the relevant economic or other interactions between the actors as initially agreed upon in the signed Parametric SLA.

3.1 SLA Standardized Monitoring

The Parametric SLA must include all the information required from the SLA document produced by the provider actor in a specified data schema format in order to function. Regarding the schema, Parametric SLA adheres to the ISO 19086-2 SLA [12] standard, which provides the necessary instructions for constructing the essential classes of the schema. The SLA document is converted via this technique into a JSON document, which is then fed into the algorithmic drivers for SLA evaluation. The specification of certain key pieces of information is necessary to build the JSON Shema that serves as the parametric SLA. These criteria are as follows:

1. Metrics: This class represents all the goals pertaining to the SLA guarantees for the service. For instance, one of the most popular metrics used for an SLA is availability. Additionally, this class contains fundamental knowledge about the metrics, primarily to allow tracking and measuring a certain metric possible.
2. Parameters: This class completes each particular metric by containing all of the precise parameters that make up that metric. It also describes the kinds of variables that express metrics and how to measure them.
3. Rules: SLA agreements include the rules by which the metrics are measured in addition to the specific metrics that they guarantee. To be more precise, the rules provide limits on how the metrics are understood; the most common application of a rule is to define what counts as a certain metric's failure or success. For example, the Amazon AWS SLA [13] defines an inaccessible service as one that is not reachable in two availability zones (in order to avoid a single point of failure).

In addition to influencing the Parametric SLA schema, parameters also affect how the SLA metrics are calculated, and consequently, how the algorithmic drivers operate (Figure 3). Algorithmic drivers must take into account all the data the Parametric SLA provides while evaluating an SLA. The rules can have such a significant impact on how the metrics are calculated that if two provider actors ever calculate the same data, they must use separate algorithmic drivers. Algorithmic drivers adopt a standard method for their creation by adhering to the SLALOM cloud specification model [14], much like the Parametric SLA.

Figure 3: Layered configuration of Algorithmic Driver

For the layered configuration of Algorithmic Drivers, the depiction of Figure 3 is analyzed as follows:

1. The Sampling Methods layer is in charge of developing the procedures for gathering sample data and assessing its reliability in order to calculate particular metrics. Essentially, the constraints that result from the rules are represented in Boolean form, and they specify whether a particular sample is saved to be utilized in computing the metric or whether it is rejected because it is invalid according to the measurement constraints.
2. The data sampling rate used to calculate the metrics, as well as the period in which they are computed and assessed, are determined by the computation layer's interval. The billing cycle and, consequently, the SLA evaluation cycle are two pieces of information that a SLA contract can provide. The SLA parameters for some services are determined once each month and every other year. 
3. The actual computation of the metrics for every given span of time is handled by the Metric Calculation layer. The sampling data is processed to create the figures for the SLA metrics using specified functions that take into account the definition and the rules that the metrics have.

After the configuration is successful, the Parametric SLA becomes the on-chain proof of the SLA agreement with all the necessary information, including the wallet addresses of the parties involved, SLA metrics information, and the Algorithmic Drivers that are used during SLA enclaved operations. The TEE acquires this new agreement entry together with the submission of the Parametric SLA Signed on the ledger and adds it to the portfolio of dedicated enclaves where it is monitored and benefited by the SLA Trusted Monitoring.

3.2 SLA Trusted Monitoring

The SLA Trusted Monitoring method for a new agreement starts after the Parametric SLA Signed is communicated to the on-chain TEE. The SLA associated and processed data is trusted and transparent to the provider actor and their client since the entire scenario evolves on-chain. The SLA monitoring and computation operations are kept secret from all other blockchain network entities that exist outside the enclaved environment. 

The most recent SLA logs are obtained and analyzed inside the TEE as soon as the Enclaved Monitoring component adds the new agreement in the dedicated enclaves portfolio. While the enveloping FPC ensures the privacy of the actions carried out by the hosted components, i.e., the smart contract structures of Enclaved Monitoring and Enclaved Comparison, the Enclaved Monitoring is deployed and operates automatically inside the implemented FPC. Every other blockchain entity that participates in the network and reads the common ledger is excluded from the FPC's blockchain activity. The Enclaved Monitoring largely consists of its own specialized smart contract functions that, using the Tunneling Shim, retrieve the most recent agreement logs from the IPFS network and recognize freshly signed agreements. The entire workflow is carried out inside the chaincode enclave while utilizing the aforementioned dedicated privacy features.

The Cloud Logger component continuously broadcasts fresh log files of an agreement to the IPFS network during the life cycle of the solution workflow. The provided Content Identifier (CID) is automatically used by the Tunneling Shim for the fetching of an agreement's logs since IPFS constitutes a content-addressed versioned P2P file system [15]. The Enclaved Monitoring connection with the IPFS nodes is facilitated by the Tunneling Shim, a specially created integration enabler. The most recent SLA logs of a certain agreement are retrieved through the Tunneling Shim and subsequently sent to the Enclaved Monitoring component, and subsequently forwarded to the Enclaved Comparison component.

Additionally, the Enclaved Comparison is a particularly designed smart contract structure that executes automatically inside the installed FPC. The announcement of the logs by Enclaved Monitoring serves as its sole trigger. The SLA computation is carried out through the Enclaved Comparison smart contract structure by calculating the potential SLA violations. In order to establish the status of an SLA violation, it uses all relevant information from the agreement, including the real metrics (log files), the agreement algorithmic driver, and the SLA agreement metrics. As expected, this computation is carried out within the FPC's private, isolated environment while utilizing the relevant TEE features, keeping it totally secure from third parties using the blockchain network. The final result of the calculations made by the Enclaved Comparison smart contract structure might or might not emit an SLA violation. The solution's final result is a fair conclusion determined in accordance with the original, clearly stated and mutually accepted SLA agreement's pre-agreed rules in the context of the indicated privacy-preserving FPC environment.

The Enclaved Comparison triggers the Refund Chaincode to be executed in the event of an SLA violation. In order to finish its operations, the Refund Chaincode actively receives all the SLA agreement information data required. The purpose of the Refund Chaincode is to fulfill the conditions of the agreement regarding possible SLA violations. As a multi-purpose chaincode, its main role is to carry out the agreed-upon compensations for violations. A penalty and reward scheme is employed for the definition of the refund mechanism that executes inside the Refund Chaincode. In the occurrence of an SLA violation during the delivery of a service, the dedicated refund mechanism is triggered. The implementation of the refund mechanism manages the system's financial equilibrium and provides the client actor with compensation for the violated SLA terms. In the event that an SLA is violated, the corresponding client actor is rewarded for the violation and their wallet balance is increased, while the provider actor is penalized and their wallet balance is decreased by the same amount. On any future SLA violation, the refund mechanism is automatically triggered. Other possible actions of the Refund Chaincode include altering the actors' reputations, the provided product score, and others. The Refund Chaincode constitutes the final component in the SLA violation procedure that completes the SLA Self-Assessment solution life cycle.

5. Conclusions

A innovative approach to SLA assessment in the context of the manifested SLA evaluation system is being described. The distributed ledger software that hosts TEEs with isolated computational capabilities serves as the foundation of the solution's concept. Since every SLA agreement is transparently evaluated from both the provider and client actors, the privacy-preserving features of such a setup benefits the whole SLA assessment life cycle, and leads towards SLA Self-Assessment in the sense that agreements can be independently evaluated inside a honest ecosystem. While the devoted SLA intelligence is isolated and carried out within the employed TEE, all activity takes place within a permissioned blockchain. The end result is a secure system that provides accuracy and computational fairness benefits to both the actors. In accordance to the underlying blockchain scalability [16], the suggested solution can scale for enterprise use cases with profitable and effectively applied interest. Future work on the system's configuration will mostly be directed toward providing more violation-agreed actions, such as adding parties reputation management and SLA product scoring inside the workflow of SLA violation handling.

References

[1] Hyperledger Fabric Private Chaincode: https://github.com/hyperledger/fabric-private-chaincode

[2] Nguyen, T.-V.; Lê, T.-V.; Dao, B.; Nguyen-An, K. Leveraging Blockchain in Monitoring SLA-Oriented Tourism Service Provisioning. In Proceedings of the International Conference on Advanced Computing and Applications (ACOMP), Nha Trang, Vietnam, 26–28 November 2019; pp. 42–50. 

[3] Ranchal, R.; Choudhury, O. SLAM: A Framework for SLA Management in Multicloud ecosystem using Blockchain. In Proceedings of the IEEE Cloud Summit, Harrisburg, PA, USA, 21–22 October 2020; pp. 33–38.

[4] Alowayed, Y.; Canini, M.; Marcos, P.; Chiesa, M.; Barcellos, M. Picking a Partner: A Fair Blockchain Based Scoring Protocol for Autonomous Systems. Proc. Appl. Netw. Res. Workshop 2018, 33–39.

[5] Uriarte, R.B.; Zhou, H.; Kritikos, K.; Shi, Z.; Zhao, Z.; De Nicola, R. Distributed service-level agreement management with smart contracts and blockchain. Concurr. Comput. Pract. Exper 2021, 33, e5800.

[6] Alzubaidi, A.; Mitra, K.; Patel, P.; Solaiman, E. A Blockchain-based Approach for Assessing Compliance with SLA-guaranteed IoT Services. In Proceedings of the IEEE International Conference on Smart Internet of Things (SmartIoT), Beijing, China, 14–16 August 2020; pp. 213–220. 

[7] D’Angelo, G.; Ferretti, S.; Marzolla, M. A Blockchain-based Flight Data Recorder for Cloud Accountability. In Proceedings of the 1st Workshop on Cryptocurrencies and Blockchains for Distributed Systems, Munich, Germany, 15 June 2018; pp. 93–98.

[8] Tan, W.; Zhu, H.; Tan, J.; Zhao, Y.; Xu, L.D.; Guo, K. A novel service level agreement model using blockchain and smart contract for cloud manufacturing in industry 4.0. Enterp. Inf. Syst. 2021, 1–26.  

[9] Sabt, M.; Achemlal, M.; Bouabdallah, A. Trusted Execution Environment: What It is, and What It is Not. In Proceedings of the 2015 IEEE Trustcom/BigDataSE/ISPA, Helsinki, Finland, 20–22 August 2015; pp. 57–64. 

[10] Hyperledger Fabric. Available online: https://www.hyperledger.org/use/fabric.

[11] Fabric Private Chaincode. Available online: https://github.com/hyperledger-labs/fabric-private-chaincode.

[12] ISO/IEC 19086-2:2018 Cloud Computing—Service Level Agreement (SLA) Framework—Part 2: Metric Model. Available online: https://www.iso.org/standard/67546.html.

[13] Amazon Compute Service Level Agreement. Available online: https://aws.amazon.com/compute/sla.

[14] SLALOM SLA Specification and Reference Model. Available online: http://slalom-project.eu/content/final-version-slalom-sla-technical-specification-and-reference-model.

[15] Benet, J. IPFS–Content Addressed, Versioned, P2P File System. 2014. Available online: https://ipfs.io.

[16] Androulaki, E.; Barger, A.; Bortnikov, V.; Cachin, C.; Christidis, K.; De Caro, A.; Enyeart, D.; Ferris, C.; Laventman, G.; Manevich, Y.; et al. Hyperledger fabric: A distributed operating system for permissioned blockchains. In Proceedings of the thirteenth EuroSys conference (EuroSys’18), Porto, Portugal, 23–26 April 2018; pp. 1–15.

License

This work is licensed under a Creative Commons Attribution 4.0 International License, creativecommons.org/licenses/by/4.0.

Acknowledgements

Psychas, Alexandros (PhD)

Kapsoulis, Nikolaos

OLDER Content

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 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 telcos. 

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.

1.2 SLA Monitoring Metrics

Typically in addition to the service description, a SLA includes a number of metrics in which the service is measured. In the Telecom industry the metrics based on which the SLA is agreed upon are as follows:

• Mean Time to Respond - The average time it takes to recover from a service failure from the time the failure was detected
• Mean Time to Resolve - The average time it takes to fully resolve a service failure
• Service Availability - The percentage uptime of the service or link

As an example, an SLA between a Tier1 and a Tier2 Telco could specify 20 minutes for Mean Time to Respond, 4 hours for Mean Time for Fault Resolution and 99% for Service Availability.

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
  -->ServiceVendor SV
  o String status
  o DateTime statusChangeDate
  o String statusChangeReason
}

transaction ResolveTicket{
  --> TroubleTicket ticket
  -->ServiceVendor SV
  o String status
  o DateTime resolutionDate
  o String statusChangeReason
}


transaction CloseTicket{
  --> TroubleTicket ticket
  --> ServiceProvider SP
  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 transaction which would populate the network with 2xCustomers, 2xServiceProviders, 2xServiceVendors.

2- Create 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

1. 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

1. 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.

1. 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

1. Motivation / Problem
2. Barriers
3. Customer Groups
4. Opportunities

5. Solution:
     Platform 
     Team
     Road map

6.  Mission
7.  Use Cases
8. 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