<liclass="toctree-l1"><aclass="reference internal"href="oracles.html#implementing-an-oracle-with-continuously-varying-data">Implementing an oracle with continuously varying data</a></li>
<liclass="toctree-l1"><aclass="reference internal"href="oracles.html#using-an-oracle">Using an oracle</a></li>
<liclass="toctree-l1"><aclass="reference internal"href="setting-up-a-corda-network.html">Introduction - What is a corda network?</a></li>
<liclass="toctree-l1"><aclass="reference internal"href="setting-up-a-corda-network.html#setting-up-your-own-network">Setting up your own network</a></li>
place when this event occurs. We already have a model for business processes in the form of <aclass="reference internal"href="flow-state-machines.html"><spanclass="doc">flows</span></a>,
so in the platform we have introduced the concept of <em>scheduled activities</em> that can invoke flow state machines
<h2>How to implement scheduled events<aclass="headerlink"href="#how-to-implement-scheduled-events"title="Permalink to this headline">¶</a></h2>
<p>There are two main steps to implementing scheduled events:</p>
<ulclass="simple">
<li>Have your <codeclass="docutils literal"><spanclass="pre">ContractState</span></code> implementation also implement <codeclass="docutils literal"><spanclass="pre">SchedulableState</span></code>. This requires a method named
<codeclass="docutils literal"><spanclass="pre">nextScheduledActivity</span></code> to be implemented which returns an optional <codeclass="docutils literal"><spanclass="pre">ScheduledActivity</span></code> instance.
<codeclass="docutils literal"><spanclass="pre">ScheduledActivity</span></code> captures what <codeclass="docutils literal"><spanclass="pre">FlowLogic</span></code> instance each node will run, to perform the activity, and when it
will run is described by a <codeclass="docutils literal"><spanclass="pre">java.time.Instant</span></code>. Once your state implements this interface and is tracked by the
wallet, it can expect to be queried for the next activity when committed to the wallet.</li>
<li>If nothing suitable exists, implement a <codeclass="docutils literal"><spanclass="pre">FlowLogic</span></code> to be executed by each node as the activity itself.
will execute the same <codeclass="docutils literal"><spanclass="pre">FlowLogic</span></code>, so it needs to establish roles in the business process based on the contract
handler to help with obtaining a unqiue and secure random session. An example is described below.</p>
<p>The production and consumption of <codeclass="docutils literal"><spanclass="pre">ContractStates</span></code> is observed by the scheduler and the activities associated with
any consumed states are unscheduled. Any newly produced states are then queried via the <codeclass="docutils literal"><spanclass="pre">nextScheduledActivity</span></code>
method and if they do not return <codeclass="docutils literal"><spanclass="pre">null</span></code> then that activity is scheduled based on the content of the
<codeclass="docutils literal"><spanclass="pre">ScheduledActivity</span></code> object returned. Be aware that this <em>only</em> happens if the wallet considers the state
“relevant”, for instance, because the owner of the node also owns that state. States that your node happens to
encounter but which aren’t related to yourself will not have any activities scheduled.</p>
</div>
<divclass="section"id="an-example">
<h2>An example<aclass="headerlink"href="#an-example"title="Permalink to this headline">¶</a></h2>
<p>Let’s take an example of the interest rate swap fixings for our scheduled events. The first task is to implement the
<codeclass="docutils literal"><spanclass="pre">nextScheduledActivity</span></code> method on the <codeclass="docutils literal"><spanclass="pre">State</span></code>.</p>
<divclass="codeset container">
<divclass="highlight-kotlin"><divclass="highlight"><pre><span></span>override fun nextScheduledActivity(thisStateRef: StateRef,
<p>The first thing this does is establish if there are any remaining fixings. If there are none, then it returns <codeclass="docutils literal"><spanclass="pre">null</span></code>
to indicate that there is no activity to schedule. Otherwise it calculates the <codeclass="docutils literal"><spanclass="pre">Instant</span></code> at which the interest rate
should become available and schedules an activity at that time to work out what roles each node will take in the fixing
business process and to take on those roles. That <codeclass="docutils literal"><spanclass="pre">FlowLogic</span></code> will be handed the <codeclass="docutils literal"><spanclass="pre">StateRef</span></code> for the interest
rate swap <codeclass="docutils literal"><spanclass="pre">State</span></code> in question, as well as a tolerance <codeclass="docutils literal"><spanclass="pre">Duration</span></code> of how long to wait after the activity is triggered
for the interest rate before indicating an error.</p>
instantiate. The reference can be checked against a per-node whitelist of approved and allowable types as
part of our overall security sandboxing.</p>
</div>
<p>As previously mentioned, we currently need a small network handler to assist with session setup until the work to
automate that is complete. See the interest rate swap specific implementation <codeclass="docutils literal"><spanclass="pre">FixingSessionInitiationHandler</span></code> which
is responsible for starting a <codeclass="docutils literal"><spanclass="pre">FlowLogic</span></code> to perform one role in the fixing flow with the <codeclass="docutils literal"><spanclass="pre">sessionID</span></code> sent
by the <codeclass="docutils literal"><spanclass="pre">FixingRoleDecider</span></code> on the other node which then launches the other role in the fixing flow. Currently
Built with <ahref="http://sphinx-doc.org/">Sphinx</a> using a <ahref="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.
