PyPI - amps-python-client - Versions diffs - 5.3.4.1__zip → 5.3.4.2__zip - Mend

amps-python-client 5.3.4.1zip → 5.3.4.2zip

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (917) hide show

amps-python-client-5.3.4.1/docs/user-guide/html/chapters/delta.html DELETED Viewed

@@ -1,609 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
-  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-  <head>
-    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
-    <title>11. Delta Messaging &#8212; AMPS User Guide develop documentation</title>
-    <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
-    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
-    <script type="text/javascript">
-      var DOCUMENTATION_OPTIONS = {
-        URL_ROOT:    '../',
-        VERSION:     'develop',
-        COLLAPSE_INDEX: false,
-        FILE_SUFFIX: '.html',
-        HAS_SOURCE:  true,
-        SOURCELINK_SUFFIX: '.txt'
-      };
-    </script>
-    <script type="text/javascript" src="../_static/jquery.js"></script>
-    <script type="text/javascript" src="../_static/underscore.js"></script>
-    <script type="text/javascript" src="../_static/doctools.js"></script>
-    <link rel="index" title="Index" href="../genindex.html" />
-    <link rel="search" title="Search" href="../search.html" />
-    <link rel="next" title="12. Conflated Topics" href="conflated_topics.html" />
-    <link rel="prev" title="10. State of the World Message Enrichment" href="enrichment.html" />
-  <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
-  <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
-  </head>
-  <body role="document">
-  <div class="document">
-      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
-        <div class="sphinxsidebarwrapper">
-            <p class="logo"><a href="../index.html">
-              <img class="logo" src="../_static/flag_logo.png" alt="Logo"/>
-            </a></p>
-  <h3><a href="../index.html">Table Of Contents</a></h3>
-  <ul>
-<li><a class="reference internal" href="#">11. Delta Messaging</a><ul>
-<li><a class="reference internal" href="#delta-subscribe">Delta Subscribe</a><ul>
-<li><a class="reference internal" href="#using-delta-subscribe">Using Delta Subscribe</a></li>
-<li><a class="reference internal" href="#options-for-delta-subscribe">Options for Delta Subscribe</a><ul>
-<li><a class="reference internal" href="#identifying-changed-records">Identifying Changed Records</a></li>
-<li><a class="reference internal" href="#conflated-subscriptions-and-delta-subscribe">Conflated Subscriptions and Delta Subscribe</a></li>
-</ul>
-</li>
-<li><a class="reference internal" href="#select-lists-and-delta-subscribe">Select Lists and Delta Subscribe</a><ul>
-<li><a class="reference internal" href="#delta-subscribe-support">Delta Subscribe Support</a></li>
-<li><a class="reference internal" href="#multiple-subscriptions-and-delta-subscribe">Multiple Subscriptions and Delta Subscribe</a></li>
-</ul>
-</li>
-</ul>
-</li>
-<li><a class="reference internal" href="#delta-publish">Delta Publish</a><ul>
-<li><a class="reference internal" href="#using-delta-publish">Using Delta Publish</a><ul>
-<li><a class="reference internal" href="#understanding-delta-publish">Understanding Delta Publish</a></li>
-<li><a class="reference internal" href="#delta-publish-support">Delta Publish Support</a></li>
-</ul>
-</li>
-</ul>
-</li>
-</ul>
-</li>
-</ul>
-<div class="relations">
-<h3>Related Topics</h3>
-<ul>
-  <li><a href="../index.html">Documentation overview</a><ul>
-      <li>Previous: <a href="enrichment.html" title="previous chapter">10. State of the World Message Enrichment</a></li>
-      <li>Next: <a href="conflated_topics.html" title="next chapter">12. Conflated Topics</a></li>
-  </ul></li>
-</ul>
-</div>
-<div id="searchbox" style="display: none" role="search">
-  <h3>Quick search</h3>
-    <form class="search" action="../search.html" method="get">
-      <div><input type="text" name="q" /></div>
-      <div><input type="submit" value="Go" /></div>
-      <input type="hidden" name="check_keywords" value="yes" />
-      <input type="hidden" name="area" value="default" />
-    </form>
-</div>
-<script type="text/javascript">$('#searchbox').show(0);</script>
-        </div>
-      </div>
-      <div class="documentwrapper">
-        <div class="bodywrapper">
-          <div class="body" role="main">
-  <div class="section" id="delta-messaging">
-<span id="delta"></span><span id="ug-delta"></span><span id="index-0"></span><h1>11. Delta Messaging<a class="headerlink" href="#delta-messaging" title="Permalink to this headline">¶</a></h1>
-<p>AMPS delta messaging allows applications to work with only the changed
-parts of a message in the SOW. In high-performance messaging, it&#8217;s
-important that applications not waste time or bandwidth for messages
-that they aren&#8217;t going to use.</p>
-<p>Delta messaging has two distinct aspects:</p>
-<ol class="arabic simple">
-<li><em>Delta Subscribe</em> - allows subscribers to receive just the fields that
-are updated within a message.</li>
-<li><em>Delta Publish</em> - allows publishers to update and add fields within a
-message by publishing only the updates into the SOW.</li>
-</ol>
-<p>While these features are often used together, the features are
-independent. For example, a subscriber can request a regular
-subscription even if a publisher is publishing deltas. Likewise, a
-subscriber can request a delta subscription even if a publisher is
-publishing full messages.</p>
-<p>To be able to use delta messages, the message type for the subscription
-must support delta messages. All of the included AMPS message types,
-except for <code class="docutils literal"><span class="pre">binary</span></code> and <code class="docutils literal"><span class="pre">struct</span></code>, support delta messages, with the
-limitations described in each section below. For custom message types,
-contact the message type implementer to determine whether delta support is
-implemented.</p>
-<p>These features can often improve performance in environments where
-bandwidth is at a premium. Since these features require AMPS to parse,
-compare, and create messages, these features can consume somewhat more
-CPU on the AMPS server than a simple publish or subscribe, particularly
-for large messages with complex structure (such as deeply-nested XML).</p>
-<div class="section" id="delta-subscribe">
-<h2>Delta Subscribe<a class="headerlink" href="#delta-subscribe" title="Permalink to this headline">¶</a></h2>
-<p>Delta subscribe allows applications to receive only the changed parts of
-a message when an update is made to a record in the SOW. When a delta
-subscription is active, AMPS compares the new state of the message to
-the old state of the message, creates a message for the difference, and
-sends the difference message to subscribers. Using this approach can
-simplify processing on the client side, and can improve performance when
-network bandwidth is the most important constraint.</p>
-<p>For example, consider a SOW that contains the following messages, with
-the <code class="docutils literal"><span class="pre">order</span></code> field as the key of the SOW topic:</p>
-<img alt="../_images/delta_original_messages.png" src="../_images/delta_original_messages.png" />
-<p>Now, consider an update that changes the status of order number 3:</p>
-<div class="highlight-javascript"><div class="highlight"><pre><span></span><span class="p">{</span>
-    <span class="s2">&quot;order&quot;</span><span class="o">:</span><span class="mf">3</span><span class="p">,</span>
-    <span class="s2">&quot;customer&quot;</span><span class="o">:</span><span class="s2">&quot;Patrick&quot;</span><span class="p">,</span>
-    <span class="s2">&quot;status&quot;</span><span class="o">:</span><span class="s2">&quot;pending&quot;</span><span class="p">,</span>
-    <span class="s2">&quot;qty&quot;</span><span class="o">:</span><span class="mf">1000</span><span class="p">,</span>
-    <span class="s2">&quot;ticker&quot;</span><span class="o">:</span><span class="s2">&quot;MSFT&quot;</span>
-<span class="p">}</span>
-</pre></div>
-</div>
-<p>For a regular subscription, subscribers receive the entire message. With
-a delta subscription, subscribers receive just the key of the SOW topic
-and any changed fields:</p>
-<img alt="../_images/delta_update_message.png" src="../_images/delta_update_message.png" />
-<p>This can significantly reduce the amount of network traffic,
-and can also simplify processing for subscribers, since the only
-information sent is the information needed by the subscriber to take
-action on the message.</p>
-<p>When the <code class="docutils literal"><span class="pre">oof</span></code> option is specified on a delta subscription, AMPS will deliver
-the full message when a previously out-of-focus message comes into focus,
-even if only some of the fields in the message have changed.</p>
-<div class="section" id="using-delta-subscribe">
-<h3>Using Delta Subscribe<a class="headerlink" href="#using-delta-subscribe" title="Permalink to this headline">¶</a></h3>
-<p>Since a client must process delta subscriptions using substantially
-different logic than regular subscriptions, delta subscription is
-implemented as a separate set of AMPS commands rather than simply as an
-option on subscribe commands. AMPS supports two different ways to
-request a delta subscription:</p>
-<table border="1" class="docutils" id="id1">
-<caption><span class="caption-text"><em>Delta subscribe commands</em></span><a class="headerlink" href="#id1" title="Permalink to this table">¶</a></caption>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<thead valign="bottom">
-<tr class="row-odd"><th class="head">Command</th>
-<th class="head">Result</th>
-</tr>
-</thead>
-<tbody valign="top">
-<tr class="row-even"><td><code class="docutils literal"><span class="pre">delta_subscribe</span></code></td>
-<td>Register a delta subscription,
-starting with newly received
-messages.</td>
-</tr>
-<tr class="row-odd"><td><code class="docutils literal"><span class="pre">sow_and_delta_subscribe</span></code></td>
-<td>Replay the state of the SOW and
-atomically register a delta
-subscription.</td>
-</tr>
-</tbody>
-</table>
-<p>Applications most commonly use <code class="docutils literal"><span class="pre">sow_and_delta_subscribe</span></code> to receive
-the current state of messages in the SOW before they begin receiving
-deltas.</p>
-</div>
-<div class="section" id="options-for-delta-subscribe">
-<h3>Options for Delta Subscribe<a class="headerlink" href="#options-for-delta-subscribe" title="Permalink to this headline">¶</a></h3>
-<p>The delta subscribe command accepts several options that are unique to
-delta subscriptions. These options control the precise behavior of delta
-messages:</p>
-<table border="1" class="docutils" id="id2">
-<caption><span class="caption-text"><em>Options for delta subscribe</em></span><a class="headerlink" href="#id2" title="Permalink to this table">¶</a></caption>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<thead valign="bottom">
-<tr class="row-odd"><th class="head">Option</th>
-<th class="head">Result</th>
-</tr>
-</thead>
-<tbody valign="top">
-<tr class="row-even"><td><code class="docutils literal"><span class="pre">no_empties</span></code></td>
-<td><p class="first">Do not send messages if no data fields
-have been updated.</p>
-<p class="last">By default, AMPS will publish a delta
-for every publish to the record, even if
-the data has not changed. By specifying
-this option, AMPS will only send messages
-when there is changed data.</p>
-</td>
-</tr>
-<tr class="row-odd"><td><code class="docutils literal"><span class="pre">no_sowkey</span></code></td>
-<td><p class="first">Do not include the AMPS generated SowKey
-with messages.</p>
-<p class="last">By default, AMPS includes this key to help
-you identify unique records within the SOW.</p>
-</td>
-</tr>
-<tr class="row-even"><td><code class="docutils literal"><span class="pre">send_keys</span></code></td>
-<td><p class="first">Include the SOW key fields in the message.</p>
-<p>Since the SOW key fields indicate which
-message to update, without this option,
-updates to delta messages will never
-contain the SOW key fields. For views, the
-SOW key fields are the fields specified in
-the <code class="docutils literal"><span class="pre">Grouping</span></code> element.</p>
-<p class="last"><em>AMPS accepts this option for backward
-compatibility. As of AMPS 4.0, this option
-is included on delta subscriptions by
-default.</em></p>
-</td>
-</tr>
-<tr class="row-odd"><td><code class="docutils literal"><span class="pre">oof</span></code></td>
-<td><p class="first">AMPS will deliver out of focus messages on
-this subscription.</p>
-<p class="last">When focus tracking is enabled, AMPS will
-also deliver the full message to a
-subscription when a previously
-out-of-focus message comes into focus.</p>
-</td>
-</tr>
-</tbody>
-</table>
-<p>Delta subscriptions also support the options provided for regular
-subscriptions, including the timestamp option and the conflation options
-described in the section on <a class="reference internal" href="pub_sub.html#ug-pub-sub-conflation"><span class="std std-ref">Conflated Subscriptions</span></a>.</p>
-<div class="section" id="identifying-changed-records">
-<h4>Identifying Changed Records<a class="headerlink" href="#identifying-changed-records" title="Permalink to this headline">¶</a></h4>
-<p>When an application that uses delta subscriptions receives a message,
-that message can either be a new record or an update to an existing
-record. AMPS offers two strategies for an application to tell whether
-the record is a new record or an existing record, and identify which
-record has changed if the message is an update to an existing record.</p>
-<p>The two basic approaches are as follows:</p>
-<ol class="arabic simple">
-<li>By default, each message delivered through a delta subscription
-contains a SowKey header field. This field is the identifier that
-AMPS assigns to track a distinct record in the SOW. If the
-application has previously received a SowKey with that value, then
-the new message is an update to the record with that SowKey value. If
-the application has not previously received a SowKey with that value,
-then the new message contains a new record.</li>
-<li>Delta messages can also contain the key fields from the SOW in the
-body of the message. This is controlled by the <code class="docutils literal"><span class="pre">send_keys</span></code> option
-on the subscription, which is always enabled as of AMPS 4.0. With
-this approach, the application parses the body of the message to find
-the key. If the application has previously received the key, then the
-message is an update to that existing record. Otherwise, the message
-contains a new record.</li>
-</ol>
-<p>In either case, AMPS delivers the information the application needs to
-determine if the record is new or changed. The application chooses how
-to interpret that information, and what actions to take based on the
-changes to the record.</p>
-<p>AMPS also supports out-of-focus notification for delta subscriptions, as
-described in <a class="reference internal" href="oof.html#ug-oof"><span class="std std-ref">Out-of-Focus Messages (OOF)</span></a>. If your
-application needs to know when a
-record is deleted, expires, or no longer matches a subscription, you can
-use out-of-focus messages to be notified.</p>
-</div>
-<div class="section" id="conflated-subscriptions-and-delta-subscribe">
-<h4>Conflated Subscriptions and Delta Subscribe<a class="headerlink" href="#conflated-subscriptions-and-delta-subscribe" title="Permalink to this headline">¶</a></h4>
-<p>AMPS provides subscription conflation on delta subscriptions. When
-conflation is enabled, each delta message during the conflation interval
-is merged into the conflated message. The message that is delivered is
-the merge of all of the deltas that arrived during the conflation
-interval.</p>
-<p>Since AMPS combines successive delta messages into a single update, a
-delta subscription that uses conflation may receive values that are
-identical to the previous values. For example, consider the following
-record in a SOW that uses <code class="docutils literal"><span class="pre">/id</span></code> as the key:</p>
-<div class="highlight-javascript"><div class="highlight"><pre><span></span><span class="p">{</span>
-    <span class="s2">&quot;id&quot;</span><span class="o">:</span> <span class="mf">99</span><span class="p">,</span>
-    <span class="s2">&quot;status&quot;</span><span class="o">:</span><span class="s2">&quot;open&quot;</span><span class="p">,</span>
-    <span class="s2">&quot;notes&quot;</span><span class="o">:</span><span class="s2">&quot;none&quot;</span><span class="p">,</span>
-    <span class="s2">&quot;xref&quot;</span><span class="o">:</span><span class="mf">82</span>
-<span class="p">}</span>
-</pre></div>
-</div>
-<p>Assume that the following updates to the record are published during the
-conflation interval:</p>
-<div class="highlight-javascript"><div class="highlight"><pre><span></span><span class="p">{</span><span class="s2">&quot;id&quot;</span><span class="o">:</span> <span class="mf">99</span><span class="p">,</span> <span class="s2">&quot;status&quot;</span><span class="o">:</span><span class="s2">&quot;questioned&quot;</span><span class="p">,</span> <span class="s2">&quot;notes&quot;</span><span class="o">:</span><span class="s2">&quot;none&quot;</span><span class="p">,</span> <span class="s2">&quot;xref&quot;</span><span class="o">:</span><span class="mf">82</span><span class="p">}</span>
-<span class="p">{</span><span class="s2">&quot;id&quot;</span><span class="o">:</span> <span class="mf">99</span><span class="p">,</span> <span class="s2">&quot;status&quot;</span><span class="o">:</span><span class="s2">&quot;questioned&quot;</span><span class="p">,</span> <span class="s2">&quot;notes&quot;</span><span class="o">:</span><span class="s2">&quot;jcarlo hold&quot;</span><span class="p">,</span> <span class="s2">&quot;xref&quot;</span><span class="o">:</span><span class="mf">82</span><span class="p">}</span>
-<span class="p">{</span><span class="s2">&quot;id&quot;</span><span class="o">:</span> <span class="mf">99</span><span class="p">,</span> <span class="s2">&quot;status&quot;</span><span class="o">:</span><span class="s2">&quot;cleared&quot;</span><span class="p">,</span> <span class="s2">&quot;notes&quot;</span><span class="o">:</span><span class="s2">&quot;none&quot;</span><span class="p">,</span> <span class="s2">&quot;xref&quot;</span><span class="o">:</span><span class="mf">82</span><span class="p">}</span>
-<span class="p">{</span><span class="s2">&quot;id&quot;</span><span class="o">:</span> <span class="mf">99</span><span class="p">,</span> <span class="s2">&quot;status&quot;</span><span class="o">:</span><span class="s2">&quot;open&quot;</span><span class="p">,</span> <span class="s2">&quot;notes&quot;</span><span class="o">:</span><span class="s2">&quot;none&quot;</span><span class="p">,</span> <span class="s2">&quot;xref&quot;</span><span class="o">:</span><span class="mf">82</span><span class="p">}</span>
-</pre></div>
-</div>
-<p>At the end of the conflation interval, the subscription will receive the
-delta message:</p>
-<div class="highlight-javascript"><div class="highlight"><pre><span></span><span class="p">{</span>
-    <span class="s2">&quot;id&quot;</span><span class="o">:</span> <span class="mf">99</span><span class="p">,</span>
-    <span class="s2">&quot;status&quot;</span><span class="o">:</span><span class="s2">&quot;open&quot;</span><span class="p">,</span>
-    <span class="s2">&quot;notes&quot;</span><span class="o">:</span><span class="s2">&quot;none&quot;</span>
-<span class="p">}</span>
-</pre></div>
-</div>
-<p>The <code class="docutils literal"><span class="pre">/id</span></code> field is included because that field is the key of the SOW,
-and all of the delta messages produced during the conflation interval
-contained that key. The <code class="docutils literal"><span class="pre">/status</span></code> and <code class="docutils literal"><span class="pre">/notes</span></code> fields are included
-because there were changes to these values during the conflation
-interval. The delta messages produced during the conflation interval
-contained changed values, so the merged update contains those fields and
-the state of the values at the end of the conflation interval. The
-<code class="docutils literal"><span class="pre">/xref</span></code> field is not included, because none of the delta messages
-produced during the conflation interval contained that field.</p>
-</div>
-</div>
-<div class="section" id="select-lists-and-delta-subscribe">
-<h3>Select Lists and Delta Subscribe<a class="headerlink" href="#select-lists-and-delta-subscribe" title="Permalink to this headline">¶</a></h3>
-<p>When a <code class="docutils literal"><span class="pre">delta_subscribe</span></code> or <code class="docutils literal"><span class="pre">sow_and_delta_subscribe</span></code> command provides a
-select list and the <code class="docutils literal"><span class="pre">no_empties</span></code> option, only changes to fields included in the
-select list will prompt a publish to the client. Changes to fields that the subscriber does not receive
-do not produce a publish.</p>
-<div class="section" id="delta-subscribe-support">
-<h4>Delta Subscribe Support<a class="headerlink" href="#delta-subscribe-support" title="Permalink to this headline">¶</a></h4>
-<p>To produce delta messages, the message type and the topic must both
-support delta subscribe. When this is not the case, AMPS accepts the
-subscription, but provides full messages rather than delta messages.</p>
-<p>All of the basic message types provided with AMPS support delta
-subscribe with the exception of the <code class="docutils literal"><span class="pre">binary</span></code> message type, <code class="docutils literal"><span class="pre">struct</span></code> message
-types, and protobuf message types that use protobuf version 3. Composite message
-types support delta subscribe if they use the <code class="docutils literal"><span class="pre">composite-local</span></code> definition,
-as described in the section on <a class="reference internal" href="messageTypes.html#ug-messagetypes-composite"><span class="std std-ref">Composite Message Types</span></a>.</p>
-<p>AMPS queues do not support delta subscribe. AMPS accepts a delta
-subscription for a queue, but produces full messages from the queue.</p>
-<p>Bookmark subscriptions do not support delta subscribe. AMPS does not accept
-a delta bookmark subscription.</p>
-<p>All other AMPS topic types that are based on a SOW support delta
-subscribe. AMPS topics that do not use a SOW do not support delta
-subscribe, and instead produce full messages.</p>
-</div>
-<div class="section" id="multiple-subscriptions-and-delta-subscribe">
-<h4>Multiple Subscriptions and Delta Subscribe<a class="headerlink" href="#multiple-subscriptions-and-delta-subscribe" title="Permalink to this headline">¶</a></h4>
-<p>When a single connection to AMPS has multiple subscriptions, AMPS sends
-the message to that client once, with information on the set of
-subscriptions that match. AMPS sends a message that will include the
-requested data for all of the matching subscriptions. For example, if a
-message matches one subscription that requests full messages and another
-subscription from the same connection that requests deltas, both
-subscriptions will receive a full message. If your application depends
-on receiving deltas, take care that the application does not issue
-non-delta subscriptions for the same set of messages on the same
-connection.</p>
-</div>
-</div>
-</div>
-<div class="section" id="delta-publish">
-<h2>Delta Publish<a class="headerlink" href="#delta-publish" title="Permalink to this headline">¶</a></h2>
-<p>Delta publish allows publishers to update a message in the SOW by
-providing just the key fields for the SOW and the data to update. When
-AMPS receives a delta publish, AMPS parses the incoming message and the
-existing messages, identifies changed fields, and creates an updated
-message that merges changed fields from the delta publish into the
-existing message. If there is no existing message, the result of a delta
-publish is the same as if the update were merged into an empty message:
-the fields in the delta publish, and only those fields, are present
-in the result.</p>
-<p>This can be particularly useful in cases where more than one worker acts
-on a record. For example, an order fulfillment application may need to
-check inventory, to ensure that the order is available, and check credit
-to be sure that the customer is approved for the order. These checks may
-be run in parallel, by different worker processes. With delta publish,
-each worker process updates the part of the record that the worker is
-responsible for, without affecting any other part of the record. Delta
-publish saves the worker from having to query the record and construct a
-full update, and eliminates the possibility of incorrect updates when
-two workers try to update the record at the same time.</p>
-<p>For example, consider an order published to the SOW:</p>
-<div class="highlight-javascript"><div class="highlight"><pre><span></span><span class="p">{</span>
-    <span class="s2">&quot;id&quot;</span><span class="o">:</span><span class="mf">735</span><span class="p">,</span>
-    <span class="s2">&quot;customer&quot;</span><span class="o">:</span><span class="s2">&quot;Patrick&quot;</span><span class="p">,</span>
-    <span class="s2">&quot;item&quot;</span><span class="o">:</span><span class="mf">90123</span><span class="p">,</span>
-    <span class="s2">&quot;qty&quot;</span><span class="o">:</span><span class="mf">1000</span><span class="p">,</span>
-    <span class="s2">&quot;state&quot;</span><span class="o">:</span><span class="s2">&quot;new&quot;</span>
-<span class="p">}</span>
-</pre></div>
-</div>
-<p>Using delta publishing, two independent workers can operate on the
-record in parallel, safely making updates and preparing the record for a
-final fulfillment process.</p>
-<p>The inventory worker process is responsible for checking inventory. This
-worker subscribes to messages where
-the <code class="docutils literal"><span class="pre">/state</span> <span class="pre">=</span> <span class="pre">'new'</span> <span class="pre">AND</span> <span class="pre">/inventory</span> <span class="pre">IS</span> <span class="pre">NULL</span> <span class="pre">AND</span> <span class="pre">/credit</span> <span class="pre">IS</span> <span class="pre">NULL</span></code>. This
-process receives the new message and verifies that the inventory system
-contains 1000 of the item # 90123. When it verifies this, it uses delta
-publish to publish the following update:</p>
-<div class="highlight-javascript"><div class="highlight"><pre><span></span><span class="p">{</span>
-    <span class="s2">&quot;id&quot;</span><span class="o">:</span><span class="mf">735</span><span class="p">,</span>
-    <span class="s2">&quot;inventory&quot;</span><span class="o">:</span><span class="s2">&quot;available&quot;</span>
-<span class="p">}</span>
-</pre></div>
-</div>
-<p>The credit worker process verifies that the customer is permitted to
-bill for the total amount. Like the inventory worker, this worker
-subscribes to messages where the
-<code class="docutils literal"><span class="pre">/state</span> <span class="pre">=</span> <span class="pre">'new'</span> <span class="pre">and</span> <span class="pre">/inventory</span> <span class="pre">IS</span> <span class="pre">NULL</span> <span class="pre">and</span> <span class="pre">/credit</span> <span class="pre">IS</span> <span class="pre">NULL</span></code>. This
-process receives the new message and verifies that the customer is
-allowed to bill the total value of the order. When the check is
-complete, the credit worker publishes this message:</p>
-<div class="highlight-javascript"><div class="highlight"><pre><span></span><span class="p">{</span>
-    <span class="s2">&quot;id&quot;</span><span class="o">:</span><span class="mf">735</span><span class="p">,</span>
-    <span class="s2">&quot;credit&quot;</span><span class="o">:</span><span class="s2">&quot;approved&quot;</span>
-<span class="p">}</span>
-</pre></div>
-</div>
-<p>After both of these processes run, the SOW contains the following
-record:</p>
-<div class="highlight-javascript"><div class="highlight"><pre><span></span><span class="p">{</span>
-    <span class="s2">&quot;id&quot;</span><span class="o">:</span> <span class="mf">735</span><span class="p">,</span>
-    <span class="s2">&quot;credit&quot;</span><span class="o">:</span> <span class="s2">&quot;approved&quot;</span><span class="p">,</span>
-    <span class="s2">&quot;inventory&quot;</span><span class="o">:</span> <span class="s2">&quot;available&quot;</span><span class="p">,</span>
-    <span class="s2">&quot;customer&quot;</span><span class="o">:</span> <span class="s2">&quot;Patrick&quot;</span><span class="p">,</span>
-    <span class="s2">&quot;item&quot;</span><span class="o">:</span> <span class="mf">90123</span><span class="p">,</span>
-    <span class="s2">&quot;qty&quot;</span><span class="o">:</span> <span class="mf">1000</span><span class="p">,</span>
-    <span class="s2">&quot;state&quot;</span><span class="o">:</span> <span class="s2">&quot;new&quot;</span>
-<span class="p">}</span>
-</pre></div>
-</div>
-<p>The fulfillment worker would subscribe to messages where
-<code class="docutils literal"><span class="pre">/state</span> <span class="pre">=</span> <span class="pre">'new'</span> <span class="pre">AND</span> <span class="pre">/inventory</span> <span class="pre">IS</span> <span class="pre">NOT</span> <span class="pre">NULL</span> <span class="pre">AND</span> <span class="pre">/credit</span> <span class="pre">IS</span> <span class="pre">NOT</span> <span class="pre">NULL</span></code>.</p>
-<div class="section" id="using-delta-publish">
-<h3>Using Delta Publish<a class="headerlink" href="#using-delta-publish" title="Permalink to this headline">¶</a></h3>
-<p>Since delta messages must be processed and merged into the existing
-SOW record, AMPS provides a distinct command for delta publish.</p>
-<table border="1" class="docutils" id="id3">
-<caption><span class="caption-text"><em>Delta publish command</em></span><a class="headerlink" href="#id3" title="Permalink to this table">¶</a></caption>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<thead valign="bottom">
-<tr class="row-odd"><th class="head">Command</th>
-<th class="head">Result</th>
-</tr>
-</thead>
-<tbody valign="top">
-<tr class="row-even"><td><code class="docutils literal"><span class="pre">delta_publish</span></code></td>
-<td>Publish a delta message. If no record exists in the
-SOW, add the message to the SOW. If a record exists
-in the SOW, merge the data from this record into the
-existing record.</td>
-</tr>
-</tbody>
-</table>
-<div class="section" id="understanding-delta-publish">
-<h4>Understanding Delta Publish<a class="headerlink" href="#understanding-delta-publish" title="Permalink to this headline">¶</a></h4>
-<p>When AMPS receives a delta publish request, AMPS first performs any preprocessing
-or enrichment specified for the incoming message. AMPS then fully parses both
-the incoming message and the destination message, and then merges the contents
-of the incoming update into the existing message. The mechanism that
-merges the messages is message-type independent, and does not rely on
-the syntax or semantics of any particular message type.</p>
-<p>The message is merged before the message is persisted to the SOW,
-recorded in the transaction log, replicated, or delivered to subscribers.</p>
-<p>Since delta publish uses a very simple, compact syntax  &#8211; a partial message
-&#8211; for updates, AMPS makes certain assumptions about the intent of an update:</p>
-<ol class="arabic">
-<li><p class="first">AMPS replaces the contents of the existing message based on the
-parsed identifiers in the update. An update to an anonymous element
-or the root level of a subdocument is a <em>full replacement</em> of that
-value.</p>
-<p>For example, consider the following JSON document:</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="s2">&quot;id&quot;</span><span class="p">:</span><span class="mi">42</span><span class="p">,</span> <span class="s2">&quot;contents&quot;</span><span class="p">:{</span><span class="s2">&quot;packages&quot;</span><span class="p">:[{</span><span class="s2">&quot;box&quot;</span><span class="p">:</span><span class="s2">&quot;chocolates&quot;</span><span class="p">},</span>
-                                  <span class="p">{</span><span class="s2">&quot;bowl&quot;</span><span class="p">:</span><span class="s2">&quot;noodles&quot;</span><span class="p">}]}}</span>
-</pre></div>
-</div>
-<p>An update to the <code class="docutils literal"><span class="pre">packages</span></code> field of the document <em>replaces</em> the
-subdocument, so providing the following <code class="docutils literal"><span class="pre">delta_publish</span></code>:</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="s2">&quot;id&quot;</span><span class="p">:</span><span class="mi">42</span><span class="p">,</span> <span class="s2">&quot;contents&quot;</span><span class="p">:{</span><span class="s2">&quot;packages&quot;</span><span class="p">:[{</span><span class="s2">&quot;basket&quot;</span><span class="p">:</span><span class="s2">&quot;eggs&quot;</span><span class="p">}]}}</span>
-</pre></div>
-</div>
-<p>Replaces the previous value of <code class="docutils literal"><span class="pre">packages</span></code>, and produces the message:</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="s2">&quot;id&quot;</span><span class="p">:</span><span class="mi">42</span><span class="p">,</span> <span class="s2">&quot;contents&quot;</span><span class="p">:{</span><span class="s2">&quot;packages&quot;</span><span class="p">:[{</span><span class="s2">&quot;basket&quot;</span><span class="p">:</span><span class="s2">&quot;eggs&quot;</span><span class="p">}]}}</span>
-</pre></div>
-</div>
-</li>
-<li><p class="first">A missing field in a delta publish means that the content
-of that field is unchanged.</p>
-<p>Since AMPS treats the absence of a field in a delta update to
-mean that the previous value is unchanged, a <code class="docutils literal"><span class="pre">delta_publish</span></code>
-cannot be used to remove fields from a document.</p>
-<p>For example, consider the following JSON document:</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="s2">&quot;id&quot;</span><span class="p">:</span><span class="mi">42</span><span class="s2">&quot;, &quot;</span><span class="n">flowers</span><span class="s2">&quot;:&quot;</span><span class="n">roses</span><span class="s2">&quot;}</span>
-</pre></div>
-</div>
-<p>A <code class="docutils literal"><span class="pre">delta_publish</span></code> that attempts to remove the <code class="docutils literal"><span class="pre">flowers</span></code> field
-by simply removing it will be treated as though there is no update
-to that field. In other words, a <code class="docutils literal"><span class="pre">delta_publish</span></code> of:</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="s2">&quot;id&quot;</span><span class="p">:</span><span class="mi">42</span><span class="p">}</span>
-</pre></div>
-</div>
-<p>will produce no change to the <code class="docutils literal"><span class="pre">flowers</span></code> field, and result in a
-document of:</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="s2">&quot;id&quot;</span><span class="p">:</span><span class="mi">42</span><span class="p">,</span> <span class="s2">&quot;flowers&quot;</span><span class="p">:</span><span class="s2">&quot;roses&quot;</span><span class="p">}</span>
-</pre></div>
-</div>
-<p>To remove a field from a message, republish the full message.</p>
-</li>
-<li><p class="first">AMPS does not evaluate whether a field has a different value than
-the previous message or has a republish of the previous value
-when processing a <code class="docutils literal"><span class="pre">delta_publish</span></code> &#8211; any field present in the
-delta publish will replace the corresponding field in the existing
-message.</p>
-<p>For example, consider an application that advertises whether
-a given system is accepting requests with messages along the
-lines of:</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="s2">&quot;systemId&quot;</span><span class="p">:</span><span class="s2">&quot;A34-Astro&quot;</span><span class="p">,</span> <span class="s2">&quot;status&quot;</span><span class="p">:</span><span class="s2">&quot;available&quot;</span><span class="p">,</span>
-                         <span class="s2">&quot;commandAccepted&quot;</span><span class="p">:[</span><span class="s2">&quot;print&quot;</span><span class="p">,</span><span class="s2">&quot;scan&quot;</span><span class="p">,</span><span class="s2">&quot;fax&quot;</span><span class="p">]}</span>
-</pre></div>
-</div>
-<p>Now, the system sends a delta publish update that does not change the status:</p>
-<div class="highlight-default"><div class="highlight"><pre><span></span><span class="p">{</span><span class="s2">&quot;systemId&quot;</span><span class="p">:</span><span class="s2">&quot;A34-Astr&quot;</span><span class="p">,</span> <span class="s2">&quot;status&quot;</span><span class="p">:</span><span class="s2">&quot;available&quot;</span><span class="p">}</span>
-</pre></div>
-</div>
-<p>Even though no value in the message has changed, the publish is still
-processed, and the publish will still be delivered to subscribers.
-The fact that it replaces an existing value with the same value
-does not matter for AMPS. This is still considered an update. (An individual
-subscriber can choose not to receive updates that do not change the value of
-a field by using the <code class="docutils literal"><span class="pre">no_empties</span></code> option with a delta subscription.)</p>
-</li>
-</ol>
-</div>
-<div class="section" id="delta-publish-support">
-<h4>Delta Publish Support<a class="headerlink" href="#delta-publish-support" title="Permalink to this headline">¶</a></h4>
-<p>To accept delta publishes, the message type and the topic must both
-support delta publish. When this is not the case, AMPS accepts the
-publish, but may not produce the expected results.</p>
-<p>All of the basic message types provided with AMPS support delta publish
-with the exception of the <code class="docutils literal"><span class="pre">binary</span></code> message type and protobuf message types
-that use protobuf version 3. Composite message types support delta publish
-if they use the <code class="docutils literal"><span class="pre">composite-local</span></code> definition, as described in the section
-on composite message types. Types that do not support delta publish, produce
-the full, literal message provided with a delta publish command (rather than
-merging the publish into the previous state of the message).</p>
-<p>When a topic uses the <code class="docutils literal"><span class="pre">composite-local</span></code> message type, parts of the
-composite that are provided as empty (that is, zero-length) are
-considered to be unchanged, and the merged message contains the existing
-contents of that part. This provides a convenient way to update only one
-part of a composite message, without having to republish data that has
-not changed. For example, a <code class="docutils literal"><span class="pre">composite-local</span></code> type contains a JSON
-part and a binary part can modify the JSON part without having to
-republish the full binary part.</p>
-<p>AMPS queues support delta publish to an underlying topic, if that
-underlying topic maintains a SOW. The merged message is provided to the
-AMPS queue.</p>
-<p>All other AMPS topic types that are based on a SOW and accept publish
-commands support delta publish. AMPS topics that do not use a SOW do not
-support delta publish, so publishing a delta message to those topics
-produces the full, literal message from the publish command rather than
-a merged message. Without a SOW configured for the topic, AMPS does not
-track the current value of a message, and therefore does not have a way
-to merge the publish into an existing message.</p>
-</div>
-</div>
-</div>
-</div>
-          </div>
-        </div>
-      </div>
-    <div class="clearer"></div>
-  </div>
-    <div class="footer">
-      &copy;2023 60East Technologies, Inc. (version develop).
-      |
-      Powered by <a href="http://sphinx-doc.org/">Sphinx 1.5.3</a>
-      &amp; <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.10</a>
-    </div>
-  </body>
-</html>

amps-python-client 5.3.4.1__zip → 5.3.4.2__zip

amps-python-client 5.3.4.1zip → 5.3.4.2zip