GET
/source/{sourceID}/orderstatusfeed
Retrieve Work Order Status Feed
Work Order Status Feed Definitions
GET /source/{sourceID} /orderstatusfeed
Retrieve Work Order Status Feed
 
Request URI
GET https://api.soa-proxy.deere.com/aglogic/source/{sourceId}/orderstatusfeed
Accept: */*
 
Request Parameters
Parameter Type Example Description Default Required?
deliverMethod string PICKUP Filter by the delivery method. This filter takes the following values: PICKUP; DELIVER; DELIVER_APPLY N/A No
 
Data Format
See the example provided and the Atom Specification ( http://tools.ietf.org/html/rfc4287)
 
Response Details
Field Type Example Description
category --- See sample response below. Includes the term and label for the category.
id string 10 Status Feed ID
title string Order GHE92.2.9 status changed. Status feed title
link --- See sample response below. Includes the href link to this status.
updated string 2015-08-20T19:31:55Z Date and time the status was last updated.
summary string Summary of this status. Status summary.
 
Sample Response in XML
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://api.soa-proxy.deere.com/aglogic/source/123/orderstatusfeed</id>
  <title>Work Order Status Feed</title>
  <updated>2016-05-25T21:30:03Z</updated>
  <link rel="self" type="application/atom+xml" href="https://api.soa-proxy.deere.com/aglogic/source/123/orderstatusfeed" />
  <entry>
    <category term="INPROCESS" label="Assigned" />
    <id>200</id>
    <title>Order GHE92.2.9 status changed.</title>
    <link href="https://api.soa-proxy.deere.com/aglogic/source/123/order/200/status" />
    <updated>2015-08-31T16:50:18Z</updated>
    <summary />
  </entry>
  <entry>
    <category term="INPROCESS" label="Assigned" />
    <id>100</id>
    <title>Order GHE92.2.9 status changed.</title>
    <link href="https://api.soa-proxy.deere.com/aglogic/source/123/order/100/status" />
    <updated>2015-08-31T16:50:18Z</updated>
    <summary />
  </entry>
  <entry>
    <category term="INPROCESS" label="Assigned" />
    <id>10</id>
    <title>Order GHE92.2.9 status changed.</title>
    <link href="https://api.soa-proxy.deere.com/aglogic/source/123/order/10/status" />
    <updated>2015-08-20T19:31:55Z</updated>
    <summary />
  </entry>
  <entry>
    <category term="COMPLETE" label="Complete" />
    <id>5</id>
    <title>Order 005006.2.3 status changed.</title>
    <link href="https://api.soa-proxy.deere.com/aglogic/source/123/order/5/status" />
    <updated>2015-08-20T18:48:03Z</updated>
    <summary />
  </entry>
  <entry>
    <category term="INPROCESS" label="Assigned" />
    <id>1</id>
    <title>Order 1 status changed.</title>
    <link href="https://api.soa-proxy.deere.com/aglogic/source/123/order/1/status" />
    <updated>2015-03-11T06:35:42Z</updated>
    <summary />
  </entry>
</feed>
 
Response Codes
Codes  
200 Success.
401 Unauthorized. There is a problem with the credentials provided.
404 Problem with the URL. Check that the URL matches the pattern described above.
500 Server error. An unexpected error occurred on the server processing your post.
Work Order Status Feed Definitions
Work Order Status Feed Definitions
A client can request the status of an order as described in the previous section. AgLogic also provides a mechanism for getting a listing of order status changes so that a client can quickly determine which orders have had status changes, and then make specific requests for those order statuses.
 
The Work Order Status Feed is implemented using the Atom Syndication Format (see: http://tools.ietf.org/html/rfc4287). The Atom Syndication Format is a standardized XML vocabulary for describing lists of timestamped entries. A client can make use of many existing open source clients for monitoring the feed, or can implement their own. While originally targeted at news feeds and blog posts, Atom is seeing adoption in a wide variety of other applications where lists of timestamped entries are used.
 
As you can see from the sample, there is a top-level node for the feed. It has a few child nodes that describe the feed, and then a collection of entries. Each entry corresponds to an order status. Once order is assigned to applicator, irrespective of whether it is unassigned, it will appear in order status feed. Below we will describe each of the important elements of the feed.
 
Updated
The updated node provides a timestamp of when this feed was published.
 
Paging Links
There are up to 5 links provided for the feed that deal with paging. Atom Syndication does not include the concept of filtering, so a client does not have the ability to limit the number of entries returned. Since Work Orders and their statuses will accumulate over time, a feed can get quite large. In order to limit the amount of data returned in a single request, the specification allows for paging. An initial response may be limited in the number of elements that are returned. If there are additional elements available, the response will contain links that allow the client to request the next page of data. There are links for first, last, next and previous pages. The next and previous links do not exist when you are at the end of the document or beginning of the document, respectively. Since the entries in the response are time ordered, with most recent being at the top of the document, and since a client will normally check the feed on a regular basis, the client will not normally need to utilize paging. All of the entries that the client has not seen will normally be on the first page.
 
Entries
There will be a single entry for each work order that has a status available. The subsections below will define the important elements in the entry.
  • Category: The category node is used to distinguish the current state of the work order. The possible states are: OPEN, INPROCESS, COMPLETE.
  • ID: The ID is the same ID that the client used when it posted the work order initially.
  • Title: The title element is meant to be human readable and is of little use to a client.
  • Link: The link element provides a link to fetch the order status details.
  • Updated: This is a timestamp of when the order status was last updated.
 
Sample Algorithm for Processing Work Order Status Feed
The following algorithm is provided for the purpose of clarity. It is divided into initial request and subsequent requests. On the initial request, the client will not have any order status data cached, so it must walk through all of the statuses (unless it has some criteria established for ignoring some of the data.) In subsequent requests, the client only needs to step through results until it gets to a timestamp that is older than its last request. Note that the client should at no time compare timestamps to its internal clock since there can be issues with latency and time accuracies. All timestamp comparisons should be relative to other timestamps in the feed.
 
Initial Request:
  1. Client makes request.
  2. Client parses response.
  3. Client saves the feed timestamp (updated node).
  4. Client reads in each entry. For each entry, the client will make an additional request for the work order status details.
  5. Client makes additional requests for additional result pages as necessary.
 
Subsequent Requests:
  1. Client makes request.
  2. Client parses response.
  3. Client saves the feed timestamp.
  4. Client iterates over the entries. When it finds an entry that has a timestamp that is older than the feed timestamp from its previous request, then it can stop iterating. At this point, all remaining entries are for statuses that the client has already processed.