I have one question on Corda, how to add node specific state variable and how to initialize them dynamically. For example I want to set different Initial amount to each node while these are created, and then perform some actions on it based on flow. Is there anything that I can use as a reference.
TIA, Lalit
In Corda 4, this will be possible using CorDapp configuration files: https://docs.corda.net/head/cordapp-build-systems.html#cordapp-configuration-files.
For the various workarounds possible in Corda 3, see https://stackoverflow.com/a/48507043/4620025.
Related
As part of our product requirements, we need to support a dynamic workflow configuration that will be set by the product's administrations.
Below is an example from Monday's system of this concept.
Meaning that the user can define the custom flow of event --> conditions / branches --> actions that will set the workflow.
Need to support events that are based on schedule and also on system configurations changes (an object changed it's state)
What is the best way to implement this on the back-end side? what module/tool should be used in order to execute the workflows?
We thought of the following design:
Create a workflow object for the whole workflow tree saving it as a hierarchical JSON object that contains the defined user hierarchy of the different objects (event, conditions, actions) and storing it in the database.
Use Apache Workflow as an orchestrator and create DAG dynamically based on the defined workflows and update them accordingly.
Is there a better tool to implement the following design? (saw some posts relating to this, but with no answer: 1, 2)
Thanks!
Structurally there is one project with two organizations. Each organization "resides" in own cartridges.
There are two gross calculations created, each has own rule set and both are registered in Component Framework.
With this configuration second defined calculation overrides first one.
How can that be architecturally solved - to separate basket calculation based on organization?
Or i will need to have one gross calculation with one rule set and in that set different rules with analyzing site/app and moving this calculation classes to some common cartridge for both organizations?
With the described preconditions you can go into the direction #johannes-metzner pointed you.
The basket calculation resolves the RuleSet implementation by its name, which is resolved by a call to a pipeline extension point.
So you could try to provide own implementations for the pipeline extenstion point ProcessBasketCalculation-GetRuleSet with higher priority then the default implementation. The implementation has to return the RuleSetName specific for your organization. The calculation should then resolve the RuleSet behind and use it for the calculation.
You can also provide different implementation app specific. So for app X in org1 you can bind your Ruleset A and for app Y in org2 you can bind Ruleset B.
I have started working on Corda recently. We have got the requirements not to show State properties for specific status.
While going through the document I have found some reference below but could not find any suitable example.
https://solutions.corda.net/corda-modelling-notation/views/views-common-concepts.html
Properties
These are the properties of the State whilst in the particular status. Not all properties need to be shown, just the ones salient to the behaviour of the State in this Status.
Could you be able to point me to any relevant example for the same?
Corda States are available to participants on a need-to-know basis and as a whole. The participant list returned by the getParticipants() method of a state defines the participants who should be aware of that state. You could update the participant list (add or remove) to grant or revoke access to a state but it's not possible to grant/revoke access to a part of the state.
To cater to your scenario below possible approaches can be taken:
Refactor your entire state into separate states and make them available to parties depending on the status.
Handle this on the application layer, after fetching the state from the Corda node and restrict visibility on the basis of the state.
Update the state variables to null based on the status, this may not be very feasible but just in case your use-case allows this.
I am writing a test for flows using MockNetwork. There is a counter-flow on one of the mock nodes that is using CorDapp's CordappContext.config to determine the course of action. I am looking for a way to pass config parameters into the CorDapps on individual mock nodes. It does not look like there is a way of doing so through MockNodeConfigOverrides, and TestCordapp.withConfig(...) only seems to apply to the network level. What am I missing?
It is possible to have different config map to CorDapps installed on different mock nodes. This has to be done through TestCordapp.withConfig(...) passed into MockNodeParameters.additionalCordapps when creating each individual node, as opposed to MockNetworkParameters.cordappsForAllNodes. Effectively the same TestCordapp needs to be applied to each mock node but the config map will be different.
In the Corda-example, if we want to add custom validating code, we can override checkTransaction() in the responder codes to make sure the IOU is above a certain threshold. This assumes that all responders are agreeable to that threshold.
What if we allow every lender to set their own threshold. In that case the threshold becomes a variable. To address this, I created a UI that directly publishes the threshold (an integer) to the database. However I am finding it hard to extract the value and passing it to a threshold variable in the flow code. Is there a better way? If this works, I can quarantine more variables and using the UI for individual nodes, I get to set custom parameters (into the database) used in the validation of the state in the Tx.
The easiest way to achieve this is to provide a different implementation of the flow for each node. For example, if you had an AcceptTxBasedOnThreshold flow, you'd create several implementations:
One AcceptTxBasedOnThreshold flow implementation for NodeA, which perhaps has a threshold of 10
One AcceptTxBasedOnThreshold flow implementation for NodeB, which perhaps has a threshold of 20 instead
And so on for any additional nodes...
You'd then create several CorDapps:
The first CorDapp would include the shared state and contract definitions that everyone uses. You'd install this CorDapp on every node. This CorDapp wouldn't include any flow definitions
You'd then create an additional CorDapp for each node:
A CorDapp with only NodeA's AcceptTxBasedOnThreshold flow. This CorDapp would only be installed by NodeA
A CorDapp with only NodeB's AcceptTxBasedOnThreshold flow. This CorDapp would only be installed by NodeB