[GR] Baselined Foreign Exchange/Price feed in SAP CAP - Simple Reference Application

[fleischr]

Grant Application

Grant Title

[GR] Baselined Foreign Exchange/Digital Asset price sync in SAP CAP - Simple Reference Application

---

Details on Grant Work

Based upon this Baseline BLIP ethereum-oasis-op/baseline-blips#34

Motivation and Overview

• Create a standalone application that maintains foreign exchange and digital asset currency rates to be used to demonstrate a business use case and a technical how-to guide of developing with the Baseline Pattern
  -The app shall retain and display data of currency price pairs. It would emphasize price pairs of fiat currencies (e.g USD to Canadian dollar, Japanese Yen, Euro etc). Digital asset prices such as ETH or BTC could be referenced as well. Enterprise systems like SAP tend to build financial systems with this data retained into a database table rather than a constant stream of API/smart contract calls each time price is used.
• Initial skeleton of the app to be delivered without any specific Baseline implementation using the SAP Cloud Application Model (CAP). CAP can be easily used in node.js, Java, or other common open-source languages. Several tutorials on how to develop using CAP are available. Unlike SAP ABAP, CAP applications can easily be run locally or deployed to the cloud. Defining the database schema, creating test data, and handling business logic can be easily achieved in typescript/Javascript and CSV files. Some examples for reference are available here: https://developers.sap.com/tutorials/cp-apm-nodejs-create-service.html, https://github.com/SAP-samples/cap-sflight. Several more examples can be found on the web; I can share other firsthand experience using CAP if needed as well. For purposes of this grant - we will choose Node.js / Javascript / Typescript.
• Create a step-by-step Baseline Implementation developer guide that walks through the SDKs and other resources that can be used to Baseline this data. We would initially use BRI-1-based APIs and SDKs to achieve this. Assuming a javascript-based integration, it could use provide-js as a Baseline SDK with the ident.provide.services, baseline.provide.services, and nchain.provide.services playing the necessary API host roles. Use of other tools like the PRVD CLI or Shuttle in the setup will be documented as well.
• a 'Non-baselined' starter/ template copy of the repo shall be available for other BRIs (ex: BRI-3/SRI) to use the same example to demonstrate their APIs/SDKs in the similar way as described above.
• Demonstrate the interoperability of Baseline between multiple systems. 2 running instances of this app could be used to Baseline with each other. It could also be synchronized to data used in the Chainlink Price Feed Integration to SAP with proUBC https://github.com/provideplatform/proubc-chainlink-fall-hackathon-2022
  -Application could be extended or forked later on to represent other related business processes and use cases (treasury, invoices/settlements, material pricing, supply chain etc)

---

Value to the Baseline Protocol

• Provides an easy to understand yet highly relevant business scenario that demonstrates Baseline's usefulness in boosting business productivity. Every business in international trade has to use foreign exchange data, but can encounter business problems if their foreign exchange data is out of sync with their international business partners.
• Synchronization digital asset prices between partners makes digital assets like ETH better suited for invoicing and real world payment
• Design choice with SAP CAP would motivate new SAP developers and integrators to engage with Baseline.
• Technical approach to building the app will be easy to follow for other Baseline core devs/maintainers being in Node.js - while also aligning to a SAP standard
• Demonstrates use of Baseline relative to another Oasis standard: oData. SAP CAP apps use oData standard to create webservices.
• Helps Baseline create a highly engaging deliverable for our sponsor SAP
• Aids all Baseline reference implementations with an easy-to-use reference application. Shows a clear before/after effect of introducing Baseline.

---

Downsides / Execution Risks / Limitations

I may have an extra busy schedule that could delay delivery at times. Milestone time frames are pre-adjusted to reflect this.
Would be glad to invite an additional collaborator to help with development tasks and share in grant funds accordingly as needed to complete.

Deliverables / Schedule / Milestones

Milestone 1 : 3 weeks. Initial application development.
Create a SAP CAP application to retrieve, store and display foreign exchange/digital asset data. CAP app would use the Fiori UI standard. At the end of this milestone, the app skeleton should be ready to show with out Baseline components added
Milestone 2: 3 weeks. Add Baseline integration to repo.
provide-js, PRVD CLI and Shuttle will be used to add Baseline to the inital app skeleton. At the end of this milestone, there should be an additional branch to the app skeleton creates/verifies baseline ZKPs upon user request or when data is changed in the application or by other triggers. We'd also test interoperability to the proUBC Chainlink Price Feed integration, particularly with the Baseline proof.
Milestone 3: 3 weeks. Create developer / business user documentation and educational materials.
At the end of this milestone, documentation should be available that guides developers in cloning the initial app and following step-by-step dev development tasks and walkthrough general Baseline configuration tasks (ex: selecting a schema, defining a workgroup, etc) to reproduce as if they did Milestone 2 by themselves. This would include a video recording. Would also like to include a blog to share a report of this POC and its use case to a broader business audience and the wider Baseline community.

---

Budget and Justification

$3000 - for initial development of the application of data model, SAP CAP application, and UI
$3000 - for adding BRI-1 / PRVD Baseline components with provide-js, test interoperability with the proUBC Chainlink Pricefeed example
$3000 - Create step-by-step Baseline Implementation developer guide, publish blog

Applicant Background

Ryan Fleischmann, SAP Architect / Developer Evangelist @ Provide.
I have over 10 years experience as a SAP architect, integrator, and developer and I am an active participant in the Baseline Core Devs meetings.

---

Community Grant Agreement

I understand and agree to the 'Process for Approved Grants' outlined here

• I agree
• I do not agree

[fleischr]

Would be included into Baseline Core Dev Onboarding Kit as well

[mehranshakeri]

Thanks @fleischr for your proposal. Could you please elaborate more on "why Baselining is necessary?" (business problem) and how Baseline solves this problem?
I also like the part mentioning BRI3/SRI. Could you please give more details how it could be helpful?
Regarding 3rd party (non Baseline) libraries, we should ensure that no dependency to those libs/APIs is introduced. Our implementation should be conformant with Baseline specs and APIs. Using one of available BRIs in Baseline repo is recommended, otherwise close alignment with SRI team. This should be an investment to improve Baseline footprint, not others.

[fleischr]

Hi Mehran @mehranshakeri

Companies collect foreign exchange rate data across a variety of different sources and time intervals, which means they can fall easily of sync to each other. Baseline introduces a mechanism by which companies can verify with each other that they're using the forex rates without having to create a direct integration channel between eachother. By being better in sync on these rates, businesses can eliminate possible disputes with eachother and run finance and supply chain processes more easily.

I should differentiate this as a simple reference application - SRI/BRI-3 is separate work. However - this does thematically align with SRI on the common goal of making Baseline more easily accessible to business IT community. I would be producing the final version of the app with BRI-1/PRVD services and components. The However I do believe the initial repo and high level instructions could be forkable to be implemented instead with BRI-3 services and components whenever they may be completed later on. That would be a good thing as it demonstrates the different BRIs having followed the same standard while being implemented in different ways.

Dependencies to 3rd party libaries - such as the ones for the SAP Cloud Application Programming model (CAPM) - would be reflected in a dedicated directory location where this grant work will reside and shall not intrude with other package.json dependencies of other ongoing projects like SRI.

Thanks for following up - hope it answers your questions. Feel free to ask anything else you'd like.

[mehranshakeri]

Thanks @fleischr for the details.

Companies collect foreign exchange rate data across a variety of different sources and time intervals, which means they can fall easily of sync to each other. Baseline introduces a mechanism by which companies can verify with each other that they're using the forex rates without having to create a direct integration channel between eachother. By being better in sync on these rates, businesses can eliminate possible disputes with eachother and run finance and supply chain processes more easily.

Just for my understanding, where does the dispute happen? Between rate providers and customers who receive rates or only between two parties who are 1. customer/trader who set a sell/buy order and 2. broker who receives and processes the order?

I should differentiate this as a simple reference application - SRI/BRI-3 is separate work. However - this does thematically align with SRI on the common goal of making Baseline more easily accessible to business IT community. I would be producing the final version of the app with BRI-1/PRVD services and components. The However I do believe the initial repo and high level instructions could be forkable to be implemented instead with BRI-3 services and components whenever they may be completed later on. That would be a good thing as it demonstrates the different BRIs having followed the same standard while being implemented in different ways.

With BRI-1 you mean the code that already exists in Baseline repo? PRVD is a brand for another OASIS project and we should not confuse them. If this is going to be base on Baseline repo implementation, that's fine, otherwise I think it will be consider a project that PRDV (the other project) should fund not Baseline. I think we had a similar situation in the past as well. Maybe others can give a better guidance on this matter.

Dependencies to 3rd party libaries - such as the ones for the SAP Cloud Application Programming model (CAPM) - would be reflected in a dedicated directory location where this grant work will reside and shall not intrude with other package.json dependencies of other ongoing projects like SRI.

Thanks. Makes sense.

Thanks for following up - hope it answers your questions. Feel free to ask anything else you'd like.

Cheers,

[fleischr]

Just for my understanding, where does the dispute happen? Between rate providers and customers who receive rates or only between two parties who are 1. customer/trader who set a sell/buy order and 2. broker who receives and processes the order?

The disputes would most likely occur in the event that businesses may invoice in one currency, but accept several others for payment. If we're out of sync on exchange rate, the party sending a payment may be thinking they've sent a full payment - but the party receiving the payment may not recognize it as such. For example: an invoice of $500 USD is paid by a customer in $680 Canadian dollars with an exchange rate of around 1 USD = 1.36 CAD. However if the invoicing parties exchange data is 1 USD = 1.40 CAD, the payment may be considered short of full payment

With BRI-1 you mean the code that already exists in Baseline repo? PRVD is a brand for another OASIS project and we should not confuse them. If this is going to be base on Baseline repo implementation, that's fine, otherwise I think it will be consider a project that PRDV (the other project) should fund not Baseline. I think we had a similar situation in the past as well. Maybe others can give a better guidance on this matter.

PRVD and BRI-1 are to be the same implementation of Baseline. Unrelated to this grant, I am part of other efforts the latest updates of BRI-1/PRVD from PRVD repos back to the Baseline repo accordingly. While this project uses PRVD/BRI-1, it will benefit other BRIs just the same with business and developer education provided with the completed grant app work itself. At another practical level - there are some features and aspects that are feature-complete in BRI-1/PRVD needed for an app like this that may not yet be available in SRI based on its current development progress. Part of the goal here is to have a common reference application by which those capabilities of different BRIs could be benchmarked to eachother.

[GoldenBit0]

Hi @fleischr, reading and commenting on this grant request is on the TSC agenda for 1/4.
This is marked as 'on hold' as the 2023 grant pool is still being determined, stand by.
Thanks!