Introduction

The combination of the business process and the supply chain plays a vital role in the determination of the performance of a business process (Polkowski et al., 2018). Lack of trust decreases the innovative nature and future development of the collaborative process with the reduction of business profit. When the service level contracts are incorrect situation there arise which is responsible for the control and process of the collaborative system of various parties and where should be the mediator process monitors. The control symmetries could be decentralized choreography in the place of the central orchestra (Olsen, 2020; Oz & Goren, 2019). The defined trust problem was addressed in the blockchain method. In the place of one party, the corresponding members may share transactional information over a wide range of untrusted nodal regions. It was achieved with the time stamped block list that recorded, shared, and aggregated information relating to the transaction that does not occur inside the BC network. The cryptographic proofs enabled immutable data storage (Sato & Himura, 2018). When the majority of the share was not compromised only transactions can be inserted. So the deleting or updating transactions may be very expensive that makes the blockchain to be tamper-proof. BC offers a wide range of computational infrastructure that runs the program which is known as smart contracts that executed the BC network for conditional payment (Weber et al., 2016).

The study developed a method for the integration of BC into choreography such that there is no requirement of central authority but required maintenance of trust. The suggested solution comprised the integration of intricate set components that permits the coordination or monitoring of the business process. The study applied the solution and described the feasibility with its employment in three case processes. The performance assessment comprised the generation of more than five hundred smart contracts followed by its execution among the eight thousand BC transactions (Prybila et al., 2020).

For obtaining the runtime verification of the business process the study explored bit coin BC suitability to develop a robust idea for choreographies. The obtained results have been realized in a fully functional software prototype. The method has been assessed in a qualitative comparative approach. The findings depicted that the BC based system enabled an execution that verifies and monitors choreographies. However, at the same time, it preserves the independence and anonymity of the participants, and performance evaluations of the corresponding prototype have also been accomplished in this study (Mendling et al., 2018).
The paper outlined the opportunities and challenges of BC for the management of the business process. The study reflected the applications of BC in the establishment of the lifecycle and context of managing the business process with the appropriate background. The study concluded the challenges of seven various research aspects (Sturm et al., 2018). The study suggested a robust lean architecture system based on BC with a smart contract for dispensing with inter-organizational combinations. The study developed a method for combining BC into the process of choreography with no central authority and trust (Wales, 2016).
The paper addressed the basic issue of trust in the execution of a collaborative process with BC and developed a method for the integration of BC into choreography such that there requires no central authority (Falazi et al., 2019). The paper addressed the problem by suggesting a business extension model that captured the BC particularities. The study also depicted the transformation of the suggested constructs into the complaint models and presented a combination of architecture that allowed the external process for the communication of BC. At last, the study validated the approach with the provision of prototypical application which proved the practical feasibility (Haarmann, 2019).

The study developed a technique for analyzing the period of the blockchain-related process. The analysis depends on the default semantics, domain-specific data, and a configuring system for BC application. The three parameters involved in this study enable better adaptability of the system to various BC techniques. The BC method slower down the task which is frequently executed with a highly automated process. Further BC could delay several physical and manual tasks that allow the entry of smart contract to finish (Rimba et al., 2017). The paper investigated the price of BC with the use of business task execution as a lens. Particularly the study compared the price for computing and storing the operation, execution on the BC over the cloud service. Initially, the study captured the cost modes for all alternative solutions. Then the study applied the business process from the state of art methods. The study observed second-order magnitude variation in the cost (López-Pintado et al., 2017).

The study introduces caterpillar, a BPMS – business process managing system that runs with Ethereum BC. The caterpillar supported the generation of various instances of the process and allowed them to track and execute the operation. The specificity of the process has been maintained on Ethereum BC and the routing workflow was done by smart contracts developed by the BPMN compiler. The targeted audience of this description comprised the investigators of BPM in BC (Tran et al., 2018).

The study presented a type of engineering framework named Lorikeet for the application of business on BC and managing assets. This method could automatically generate well tested contract code from the specified encoded business system on the basis of model transformations. The study demonstrated the suggested system with the industrially used case (Meroni et al., 2019). The paper investigated the issues of trust artifact monitoring like identification during execution and overcoming the misleading and fake information. The paper focused on future researches which are sensor data quality improvement, the escrow process, sidechaining, and oracles (Viriyasitavat, 2018).

The paper investigated the selection and comprising of services in the open business platform that has been explored and suggested the transfer and verification of partner and business trust, A BPM framework was generated for the illustration of the mechanism of BCT concerning reliable, prompt, and cost-efficient assessment and transfer of QoS in the management and composition of the workflow (García-Bañuelos et al., 2017).

The paper suggested an optimized technique for the execution of the business process in the case of the commodity BC method. The paper presented a technique for the compilation of a process model and encoded the pre-determined conditions for task execution with the space enhanced data structure. The technique was compared empirically with the existing baseline system with execution logs comprising of the measurement of resource consumption and real-time business operation (Fridgen et al., 2018). The research revealed that tamper-proof operation for automated manual processed steps followed by the decentralized system could be major advantages of BC for the organizational management of the workflow. Apart from that the research provided the insights of the BC utilized for the business management process.

The paper adopted BC for addressing the lack of trust in addressing the trust problem in the collaborative business process. The prevailing works in virtual organizations, the operations are performed based on disclosure credentials and policies and possess low reliability, conformance, and quality of services. They do not resolve the trust issue and the collaborating parties may corrupt the information. Further trust has been obtained as an emergent and temporary solution in the existing works. Unconfirmed messages enter the state of the process in the existing works. The proposed work attempted to overcome the challenges and allows the participants to execute the process successfully.

The paper adopted the blockchain methodology for addressing the trust problem in the process of business management. In specific, the study developed an idea for mapping a business process to peer to peer execution and storage of transaction on the blockchain that offered low benefits. Initially, the study provided a facility that integrated an immutable and automatic history of the transaction. Then smart contracts may be utilized for the direct implementation of the control logic. At last, the study obtained an audit trail for completing the collaborative process of the concerned.

Objective

The main contribution of the paper

• To investigate the utilization of blockchain technology for establishing trust and verification of the choreographies

• To evaluate the generated prototype with the qualitative performance analysis.

• To assess the feasibility of the approach.

Paper Organization

The paper is organized into 5 main sections such as Section 1 deals with the introduction of the blockchain into the business process management and section 2 designates the process within the existing works. Section 3 demonstrated the performance evaluation of the proposed system and section 4 expounds the result and discussion of the entire setup. Section 5 concludes the work and section 6 is the references included in the research work.

Research Methodology

The paper proposed a collaborative execution of the process based on blockchain for addressing the trust problem. Various technical complexities may arise during the employment of BC in the processing of transactions, data storage, and computation. But smart contracts may not be called outside the BC environment for the creation of BC transactions. The proposed system in figure 1 elaborates in detail about the problems encountered.

The proposed flow is explained as follows. The study utilized blockchain for facilitating the integrative process in any of the two following methods.

• Choreography monitor

• Active mediator

Choreography Monitor

It stores the status of the process execution of the participants through observing the exchange of informative messages. Here BC functions as immutable data for sharing the process execution status and generation of audit trail.

The smart contracts periodically check whether the interactions are conformed to the considered choreography model. Further, a kind of choreography monitor could be utilized for managing escrow and automated payment points.

Active Mediator

The active mediator coordinates the execution of the collaborative process. It includes smart contracts for driving the process and the application data calculations or transformations. The main components that support the system are as follows.

• During the design time, a translator obtained from the specification that has been described in BPMN

• Script language

The created smart contracts function as a factory for mediating the choreography monitors. The C-monitor tracks the choreography instances and is integrated into a grouped view of the execution. It could trigger conditional pay from the escrow where some points in the choreography have reached. A mediator utilizes the smart contract for the implementation of collaborative business. With the employment of c-monitor, it has been split in between the factory and instances that provide a process state consolidated view. But the mediator performed an active role that receives and sends messages as per the business logic described in the process model. It also transfers information and executes other such computations. Triggers or interfaces could not connect the operation that executed BC and the external world. Since smart contracts could not directly connect apart from BC, A trigger functions as an organization agent. It withstands confident data and performs on the complete BC node by tracking of the context and performing business process status.

C-Monitor utilizes smart contracts for monitoring the business that has been split into case-specific and factory C-monitors. An active mediator utilizes a smart contract for implementing the business model. It has also been splintered as like the C monitor to observe the process state. The translator is utilized at the design time and it takes and prevailing BPM as input that creates smart contracts. These process the C monitor or mediator and could be employed and executed on the blockchain. Triggers are the programs running on complete nodes of BC. In a characteristically setup, all the participants can communicate with the trigger. For preserving the privacy of the participants involved, the study has the option for the encryption of the data payload before the BC. The C- monitor or the mediator could also perform as the Escrow for the conditional payment as designed points. Like the escrow agent, in real estate transactions, the Smart contract obtains money from other parties.
With the help of prescribed components, the process achieved

•Participants may execute the integrative process over the untrusted nodes.

•Confirmed messages may progress the process state.

•Escrow and payments may be coded to the process the immutable ledger kept all the transactions to be successful.

The selecting methods for the list were provided in the following algorithm.

Procedure Selec tUpcoming Component (Component, Upcoming Component)

〖for all  E〗_j  ∈OE[Component]do

if E_j∙TargetComponent==T then

UpcomingComponent= E_j∙TargetComponent

else if E_j∙TargetComponent==AND-Join Gateway then

UpcomingComponent= E_j

else if E_j∙TargetComponent==XOR-Join Gateway then

SelectUpcomingComponent

(E_j∙TargetComponent,UpcomingComponents )

end if

end for

end Procedure

Procedure SelectPrecedingComponent

(Component,PrecedingComponent[])

PrecedingComponent= Component

if Component==T then

〖for all  E〗_j  ∈IE[Component]do

if E_j∙SourceComponent==XOR-Split Gateway then

SelectUpcomingComponent(E_j∙SourceComponent,PrecedingComponents)

end if

end for

else if

Component== AND-Join Gateway then

〖for all  E〗_j  ∈IE[Component]do

PrecedingComponent= E_j

end for

end if

end Procedure

The overall translation algorithm possesses two phases in which the translator process the input model and the iteration has been performed through the entire component, in which it develops two kinds of lists per components: one for the upcoming component and one for the preceding component. Then the translator transforms every component with the respective links that develop solidity code based on translation rules for various types of components. The preceding elements list has been utilized by the translator for the determination where the other components have to be deactivated during the execution of the present component. The upcoming component list denoted the component to be activated after the execution of the present component.

Here next components of the composition comprise all the tasks which directly proceed with the component or outgoing edge when the edge target is AND join.

If the UC –upcoming component is XOR-Join or split gateway the edges that link to it was included in UC –upcoming component through recursive call.

The preceding component (PC) of the component adds the components by itself.

IF XOR- split follows the present component the underlying tasks were included in the Preceding Component (PC). In the case of AND –join gateway all kinds of incoming edges were included in the preceding component (PC). The generator system has been based on the workflow pattern. Few patterns could be directly translated, few to be off-chain support and few are not necessary in the case. The key aspect does not support all the BPMN components but initiates from the basic control of patterns.

After the development of the smart contracts the cost range for the execution of obtaining smart contracts was measured by the translator. This indicated the number of crypto coins to be processed for the process execution over BC.

The translation rules are provided in Table 1.

Table 1 Translational Rules
Element of BPMN	Summary of Solidity code	Scope
XOR join	Implements one incoming edge on the activation	All
XOR split	Implements all subsequent edge on a conditional basis.	All
Parallel join	Implements all incoming edge on the activation	All
Parallel split	Implements all subsequent edge	All
Overall patterns	When implemented it could deactivate by its own followed by the activation of the subsequent components	All
Data transformation task	Mediator int-logic handling	M
	On-chain - mediator
	Off-chain –trigger
Payment Task	After conformation escrow processing	M, CME
	Incoming payment-by transaction
	Outgoing payment-account with the determining role
Choreography task	Implements the operation when the corresponding message has been received in the form of BC transaction and correspondingly executed the task activation	All

Measurement of Latency

The study measured latency concerning the time taken for the trigger to receive the API call until it transmits the signals with the conformance result, block number, and transaction hash. A test script has been iterated along with the cases and synchronous calls for all the events. Hence the test script transmits the next request immediately after obtaining the response, which distorted the measurement of the latency. Figure 2 explains that the period for a particular block to explore arrives from the task complexity that is characteristically framed to be computationally complex. In the proposed system the obtained latency is 2.3 seconds that is more suitable for more practical implementations.

Conformance Checking

Tables 2 and 3 explain the following. It is investigated that the execution clearly described the non-conforming trace for the generation of every model. The results depicted that all the log traces have been classified correctly which is the main requirement of the proposed system.

Table 2 Use Case Features and Checking of Conformance
Process	T	GW	Traces
			conform	not conform
Supply chain process	15	2	6	55
Incident management	10	7	5	134
Incident management with payment	10	7	5	16
Insurance Claim	18	9	19	258

Table 3
Use Case Features and Checking of Conformance
Process	T	GW	Traces
			Calculation	String manipulation
Incident management with data transfer	9	7	11	11

Run Time Verification

Table 4 depicts the following when the system is operating in the mode; the runtime verification exhibited a considerable increase in the duration of the execution when compared with the verification reduced baseline. The effect of the verification system on the duration of the execution has been decreased when compared with other runs. This acts as a valid scenario because the task has been documented by the transaction which is signed by receiving and sending participants.

Table 4 Run Time Verification
Process	Tasks covered	Evaluation Runs	Total no of tasks	Mean Duration[s]	S.D
#1	7	4	27	704	432
#1	5	6	19	653	955
#2	6-8	4	26	712	312
#2	6	5	26	4,040	7,254
#3	12-15	4	44	543	221
#4	11	3	38	2,822	2,038
#4	13	5	62	1,144	565
		Total	242

Conclusion

Lack of trust remains the main issue in the collaborative executing process. The paper utilized the blockchain method followed by the smart contracts (SC) for circumventing the conventional requirement for the centralized trust participant. Here a translator for translating the specification of the process into SC this could be executed on BC. Then the study utilized a computational structure for coordinating the business process. Nest for connecting the smart contracts with the external world trigger concept has been established. Several benefits of the proposed approach comprise the building of escrow option and permitting the automated payments into the operation thereby the BC transactions from the execution of process frames an immutable audit trail. Additional benefits of our approach include the option to build escrow and automated payments into the process, and that the blockchain transactions from process executions form an immutable audit trail.

Acknowledgement

We extend our thanks to King Faisal University and Saudi Electronic University for their continuous support and motivation to complete our paper.

References

1. Polkowski, Z., Nycz, M., & Borah, S. (2018). "Blockchain implementation in business." Scientific Bulletin-Economic Sciences, 17, 187-196.
2. Olsen, C. (2020). "A brief review on blockchain integrated Enterprise Resource Planning (ERP) in Accounting: What, why and how? Current research in enterprises, systems, accounting and management, 9.
3. Öz, S., & Gören, H.E. 2019. "Application of Blockchain technology in the supply chain management process: Case studies." Journal of International Trade, Logistics and Law, 5, 21-27.
4. Sato T., & Himura, Y. (2018). "Smart-contract based system operations for permissioned blockchain." In 2018. 9th IFIP International Conference on New Technologies, Mobility and Security (NTMS), 1-6.
5. Weber, I., Xu, X., Riveret, R., Governatori, G., Ponomarev, A., & Mendling, J. (2016). "Untrusted business process monitoring and execution using blockchain." In International Conference on Business Process Management, 329-347.
6. Prybila, C., Schulte, S., Hochreiner, C., & Weber, I. 2020. "Runtime verification for business processes utilizing the Bitcoin blockchain." Future Generation Computer Systems, 107, 816-831.
7. Mendling, J., Weber, I., Aalst, W.V.D., Brocke, J.V., Cabanillas, C., & Daniel, F. (2018). "Blockchain for business process management-challenges and opportunities." ACM Transactions on Management Information Systems (TMIS), 9, 1-16.
8. Sturm, C., Szalanczi, J., Schönig, S., & Jablonski, S. (2018). "A lean architecture for blockchain based decentralized process execution." In International Conference on Business Process Management, 361-373.
   Wales, N.S. (2016). “Using blockchain to enable untrusted business process monitoring and execution”.
9. Falazi, G., Hahn, M., Breitenbücher, U., & Leymann, F. (2019). "Modeling and execution of blockchain-aware business processes." SICS Software-Intensive Cyber-Physical Systems, 34, 105-116.
10. Haarmann, S. (2019). "Estimating the duration of blockchain-based business processes using simulation." In ZEUS, 24-31.
11. Rimba, P., Tran, A.B., Weber, I., Staples, M., Ponomarev, A., & Xu, X. (2017). "Comparing blockchain and cloud services for business process execution." In 2017 IEEE International Conference on Software Architecture (ICSA), 257-260.
12. López-Pintado, O., García-Bañuelos, L., Dumas, M., & Weber, I. (2017). "Caterpillar: A Blockchain-Based Business Process Management System." In BPM (Demos).
13. Tran, A.B., Lu, Q., & Weber, I. (2018). "Lorikeet: A model-driven engineering tool for blockchain-based business process execution and asset management." In BPM (Dissertation/Demos/Industry), 56-60.
14. Meroni, G., Plebani, P., & Vona, F. (2019). "Trusted artifact-driven process monitoring of multi-party business processes with blockchain." In International Conference on Business Process Management, 55-70.
15. Viriyasitavat, W., Da Xu, L., Bi, Z., & Sapsomboon, A. (2018). "Blockchain-based business process management (BPM) framework for service composition in industry 4.0." Journal of Intelligent Manufacturing, 1-12.
16. García-Bañuelos, L., Ponomarev, A., Dumas, M., & Weber, I. (2017). "Optimized execution of business processes on blockchain." In International Conference on Business Process Management, 130-146.
17. Fridgen, G., Radszuwill, S., Urbach, N., & Utz, L. (2018). "Cross-organizational workflow management using blockchain technology-towards applicability, auditability, and automation." In Proceedings of the 51st Hawaii International Conference on System Sciences.