Learn with the Demo App
You may not have realized it yet but your P6 instance came with a ready-to-install Demo App.
This Demo App has been designed and built to help developers understand how they can create applications on Platform 6. It is a feature-rich app that supports an elaborate scenario and provides examples of service items (Routes, Scripts, Workflow Steps…) that can be leveraged for developing other apps.
We advise you install the Demo App on your instance and play with it, navigating between the user interface and this page to understand how it works.
Note that you can un-install the Demo App whenever you want. The un-installation scripts will take care of deleting all the transactions and workflow tasks related to the app - so you’ll find your instance as clean as it was before the app was installed.
Installation of the P6 Demo App¶
Log on your Platform 6 instance via portal.platform6.io, click on the ‘Applications’ menu entry, then hit the ‘Install’ button in the ‘Actions’ column in the grid displaying the ‘Packaged applications’.
The installation process takes a few seconds - and you get the following screen once completed:
You may then hit the ‘Close’ button… and here you go, the Demo App is installed and running.
Happening during installation¶
The Platform 6 installation process relies on Docker Compose to launch a set of containers - see complete list here. One of them, called ‘demobc’ is a single Ethereum blockchain node (Hyperledger Besu) only used by the Demo App to store its transactions.
At installation, the Demo App deploys a smart contract to that demo blockchain. The smart contract is written in Solidity, and its source code is available on Github. That code is then fed to the Platform 6 Solidity Jar Builder which generates Java classes that allow to deploy the smart contract, call exposed functions, submit transactions and listen to events from Java code. The resulting JAR file is included as a bundled resource in the Demo App.
This bundled resource is deployed in the PreInstallApplication script in order to add the generated Java classes to the classpath. Then, in the PostInstallApplication script (line 23), the Demo App deploys the smart contract and stores the deployed smart contract address in the App Config to be later used to issue blockchain transactions and listen to events coming from the blockchain.
Supported scenario¶
The P6 Demo App simulates a buyer-supplier relationship with a set of transaction types (Requests for Quotation, Quotes and Purchase Orders) being exchanged via an Ethereum smart contract. Behind the scenes, the App plays the role of the Buyer; you (logged-in user) play the role of the Supplier.
Step-by-step details¶
Step 1 (Buyer side) – A Request for Quotation (RFQ) is created every 10 minutes and stored in a smart contract
P6 service items leveraged to perform this step:
| Service item name (Type) | What it does |
|---|---|
| SchedulerForRFQCreation (Route Deployment Script) | – Calls the CreateRFQTransaction script every 10 minutes |
| CreateRFQTransaction (Script) | – Generates a UBL RFQ containing 1 to n lines (n being the number of different categories in the ‘Items’ table) with requested quantity on each line being randomly generated (1 to 10) – Writes the UBL RFQ in the blockchain smart contract leveraging the RFQSmartContractHelper script |
| RFQSmartContractHelper (Script) | – Makes it easy to interact with the smart contract |
Step 2 (Supplier side) – The UBL RFQ is retrieved from the smart contract and an RFQ Transaction is created on P6
P6 service items leveraged to perform this step:
| Service item name (Type) | What it does |
|---|---|
| BlockchainEventHandler (Route Deployment Script) | – Creates a route that listens to a specific smart contract, on a specific Ethereum node (both being defined in the AppConfig table) – Submits Ethereum logs to the BlockchainEventHandler script |
| BlockchainEventHandler (Script) | – Handles logs retrieved from the smart contract and if the event relates to a received RFQ, calls the ReceiveRFQTransaction script |
| ReceiveRFQTransaction (Script) | – Handles the reception of the RFQ (creation of the RFQ TransactionInfo item with a “Received” technical status code, storage of the UBL RFQ on the file system…) – Saves the TransactionInfo item and sends it to the Routing Rules Dispatcher route endpoint (p6router.p6_demo_Dispatcher) |
| RoutingRuleDispatcher (Route Deployment Script) | – Submits to the appropriate route based on the Transaction type – so in this case, to the Routing Rules for RFQs route endpoint (p6router.p6_demo_RequestForQuotation) |
Step 3 (Supplier Side) - The received RFQ triggers a P6 workflow, which offers two options to the supplier user: either (a) provide a Quote or (b) decline the RFQ
P6 service items leveraged to perform this step:
| Service item name (Type) | What it does |
|---|---|
| RoutingRulesForRFQs (Route Deployment Script) | – Triggers the HandleRequestForQuotation workflow step because the value of the technical status code of the routed RFQ Transaction equals “Received” |
| HandleRequestForQuotation (Workflow Step) | – Creates a workflow task with two possible actions, either “Provide Quote” (which will trigger the WFHandleRFQ-ProvideFormForQuoteCreation script to create the custom form and execute the WFHandleRFQ-HandleActionProvideQuote script after submission) or “Decline” (which will execute the WFHandleRFQ-HandleActionDecline script after submission) – Assigns the workflow task to all users with a *=* scope that are assigned at the root of the instance organization |
Step 4.a (Supplier Side) - The Supplier user decides to provide a Quote in reply to the received RFQ
P6 service items leveraged to perform this step:
| Service item name (Type) | What it does |
|---|---|
| WFHandleRFQ-ProvideFormForQuoteCreation (Script) | – Displays a custom form allowing the supplier user to (i) select items from the mini catalog hosted in the Items table (ii) enter discount on each line item (iii) submit the Quote |
| WFHandleRFQ-HandleActionProvideQuote (Script) | – Updates the RFQ TransactionInfo item statuses (technical status to ‘Handled’ and function status to ‘Quote provided’), creates the UBL Quote based on elements provided by the user, creates the Quote TransactionInfo, saves and routes it (calling the Dispatcher endpoint) |
| RoutingRuleDispatcher (Route Deployment Script) | – Submits to the appropriate route based on the Transaction type – so in this case, to the Routing Rules for Quotes route endpoint (p6router.p6_demo_Quote) |
| RoutingRulesForQuotes (Route Deployment Script) | – Triggers the SendQuoteToBlockchain script because the value of the technical status code of the routed Quote Transaction equals “Created” |
| SendQuoteToBlockchain (Script) | – Sends the Quote to the blockchain smart contract and updates the Quote status on the TransactionInfo item to “Sent” |
Step 4.b (Supplier Side) - The Supplier user decides to decline the RFQ and can enter a reason
P6 service items leveraged to perform this step:
| Service item name (Type) | What it does |
|---|---|
| WFHandleRFQ-HandleActionDecline (Script) | – Updates the RFQ TransactionInfo item statuses (technical status to ‘Handled’ and function status to ‘Declined’) and declines the RFQ on the Ethereum smart contract |
Step 5 (Buyer Side) - The Buyer receives the Quote via the blockchain and generates a Purchase Order matching the Quote
P6 service items leveraged to perform this step:
| Service item name (Type) | What it does |
|---|---|
| BlockchainEventHandler (Route Deployment Script) | – Creates a route that listens to a specific smart contract, on a specific Ethereum node (both being defined in the AppConfig table) – Submits Ethereum logs to the BlockchainEventHandler script |
| BlockchainEventHandler (Script) | – Handles logs retrieved from the smart contract and if the event relates to a received Quote, calls the HandleQuoteTransaction script |
| HandleQuoteTransaction (Script) | – Handles the creation of the UBL PO by flipping the Quote and its storage on the file system – Creates the PO TransactionInfo item, then saves and sends it to the Routing Rules Dispatcher route endpoint (p6router.p6_demo_Dispatcher) |
Step 6 (Supplier Side) - The received PO triggers a P6 workflow, which offers two options to the supplier user: either (a) accept the Order or (b) reject it
P6 service items leveraged to perform this step:
| Service item name (Type) | What it does |
|---|---|
| RoutingRulesForPurchaseOrders (Route Deployment Script) | – Creates a route that triggers the HandlePurchaseOrder workflow step because the value of the technical status code of the routed PO Transaction equals “Received” |
| HandlePurchaseOrder (Workflow Step) | – Creates a workflow task with two possible actions, either “Accept Order” (which lets the user enter a Sales Order Number and then executes the WFHandlePO-HandleActionAcceptOrder script after submission) or “Reject” (which lets the user enter a rejection reason and the execute the WFHandlePO-HandleActionRejectOrder script after submission) – Assigns the workflow task to all users with a *=* scope that are assigned at the root of the instance organization– Notifies the assignees via email (leveraging the WFHandlePO-BuildEmail script and the POReview email html template from the bundled resources) |
| WFHandlePO-BuildEmail (Script) | – Customizes the email notification sent to the workflow assignees (in particular, handles the insertion of the link presented in the email so the user is directly presented the Purchase Order to approve |
| POReview (Bundled Resource) | – Provides the html template for the email notification |
Step 7.a (Supplier Side) - The Supplier user decides to accept the PO and can enter a Sales Order Number
P6 service items leveraged to perform this step:
| Service item name (Type) | What it does |
|---|---|
| WFHandlePO-HandleActionAcceptOrder (Script) | – Updates the PO TransactionInfo item statuses (technical status to ‘Handled’ and function status to ‘Accepted’), adds the Sales Order Number as a Key Value in the PO TransactionInfo item, then saves and routes |
Step 7.b (Supplier Side) - The Supplier user decides to reject the PO and can enter a rejection reason
P6 service items leveraged to perform this step:
| Service item name (Type) | What it does |
|---|---|
| WFHandlePO-HandleActionRejectOrder (Script) | – Updates the PO TransactionInfo item statuses (technical status to ‘Handled’ and function status to ‘Rejected’), then saves and routes |
Installation & uninstallation¶
When creating an app, you can define scripts that will be executed before or after installation (‘Pre-install script’ and ‘Post-install script’) and a script that will be executed if and when the app is uninstalled (‘Uninstall script’).
For the P6 Demo App, the ‘InitializeApplication’ script is set as the ‘Post-install script’ and handles the following tasks:
- Copy all bundled resources to the local file system
- Populate the ‘Items’ table with records from a CSV file (p6_demo_items.csv)
- Save a demo wallet to interact with the smart contract
- Deploy a smart contract to the local Ethereum node
- Define a custom transaction manager with a polling frequency of 2 seconds
- Save the Ethereum contract address and Ethereum client URL in the ‘AppConfig’ table
- Notify Platform 6 that the installation was successful
The ‘UninstallApplication’ script performs the following tasks:
- Execute the ‘DeleteP6DemoTransactions’ store procedure, which will delete all transactions and workflow tasks created by the Demo App
- Destroy all routes (routing rules, scheduled tasks, blockchain event listener…)
- Undeploy bundled resources
- Notify Platform 6 that the uninstallation was successful