- High-Level Architecture
- Analytics / Data Export Service (DES)
- OAuth2 Client
- REST API
- Cloud Environment
- Local Environment
Analytics / Data Export Service (DES)
Jive Derby uses DES in a limited fashion, mainly to show how information from DES can complement existing systems/algorithms to blend awareness of activity in Jive!
For more details, see: Tiles > Custom View Tile - External (Popular Races) to learn about how a make-shift "popular" algorithm based on DES was created to power a Jive Tile experience.
Jive's App Framework allows developers to integrate experiences into the Jive user experience in a rich and context aware manner. While the Jive Derby could easily extend deeper into Jive, it focuses on 2 primary scenarios in its inaugural launch.
External Objects (See Figure 1)
The Jive Derby cloud environment submits racer and race details to Jive in the form of an external object. The external object is defined as having an app view (ext-object) which tells Jive to use the App to render the experience, in lieu of the standard location. This allows Jive to attribute additional collaboration services around the external object, such as Shares, Bookmarks, Likes, Comments and Structured Outcomes.
Profile Page - Tab + NavBar (See Figure 2)
When external objects are created, the Jive Derby cloud environment is notified by Jive via webhooks that allows Jive Derby to map races to content Jive objects. Once mapped, the cloud environment marks each Jive external object with ExtProps metadata that is used to support this app experience. This allows Jive to have a native API to conceptually filter Jive objects by derby, winner and racer, while also displaying additional meta-data associated with the app.
By virtue of being a middleware service, Jive Derby is also an OAuth2 Client. It uses an OAuth token obtained during the Activity Stream setup to query and call APIs on behalf of the person who setup the stream. This OAuth token is also used to proxy profile information to the Local Environment through the Jive Proxy service.
Note: For simplicity, Jive Derby currently supports only a single OAuth token at a time. While it is common for middleware services to store and manage multiple OAuth tokens at a time, we wanted to focus more on the high-level capabilities. Should you have questions about supporting multiple tokens with your middleware, you might want to check out the Github4Jive project, which shows how this would work.
When creating Add-Ons, it is possible to specify a "config_url" in the Add-On's meta.json file, which will force the installing using the configure the add-on when installed. Typically, this experience is used to collect System level configuration information, such as a shared OAuth token for all sub-components, license keys, etc...
In the case of the Jive Derby, we dont need/want this level of elevated access, so this screen is simply an pop-up with a Save button, but it has been wired to insure that if someone wanted to drop additional details ... it would be easy.
Note: If you wanted to move OAuth token grant to this phase you could, you would just simply need to port code from the JiveDerby-RaceActivity tile (below) to this experience. See Figure #2
An Activity Stream Tile is a popular way of bringing in external system activity into Jive in a rich and interactive manner. When a Jive Derby race completes, the data is aggregated and posted to Jive as an External Object Activity. An externalID field is added to the Jive Object which allows Jive Derby to map the external object to the race. A Jive App is leveraged to customize the content presentation to reflect the Jive Race details. This one integration types powers numerous other facets of the Jive Derby, so understanding this is key!
When the activity stream is added to a place and configured, the configuration experience offers the user the ability to authorize Jive Derby to support this derby and place on their behalf. This is an example of a delegated pattern of authorization, such that, administrators are not needed authorization and yet authorization tokens granted will not exceed the permissions of the authorizing user. As a person who has access to administrate the Jive place's Tile page, they should have ample rights to perform any administrative function to the place, should Jive Derby require it.
Custom View Tile - Internal (Your Races)
Custom View Tiles are a powerful way to impact the Jive user experience via a component on a Page. This example demonstrates how Custom View Tiles can be published in Jive, such that display resources, assets AND DATA are stored in Jive. This means that developers can create experiences that store information entirely in Jive, that, when rendered, can stitch together external and internal resources for a dynamic and interactive experience.
Note: Custom View Tiles (Internal) are able to interact securely with Jive services (scoped as the current user) or remote services to mash information from Jive and third-party service for an integrated user-experience within the Tile. This makes them inherently different from a standard Data Tile, which has a single data context for all viewers (minus the Action functionality), allowing them to personalize the experience to the view.
Custom View Tile - External (Popular Races)
Custom View Tiles are a powerful way to impact the Jive user experience via a component on a Page. This example demonstrates how Custom View Tiles can be published in Jive, such that display resources and assets are stored in Jive; however, the Tile data context is pushed into Jive from an external service in a completely decoupled manner from the user browsing session. In essence, Custom View Tiles (External) are Jive Data Tiles with a custom user experience.
Note: Custom View Tiles (External) are able to interact securely with Jive services (scoped as the current user) or remote services to mash information from Jive and third-party service for an integrated user-experience within the Tile. This makes them inherently different from a standard Data Tile, which has a single data context for all viewers (minus the Action functionality), allowing them to personalize the experience to the view.
Gallery Tile (Race Photos)
Gallery Tiles are an easy way to make an instant visual impact in your community. A Gallery Tile simply receives a list of images and supports the UX to page through each image (including Full Screen) with simple caption labels. In our case, we are using the Gallery Tile to show a list of the most recent races (animated GIFs) so people can see what they are missing.
List Tile (Top Racers)
List Tiles are the bread and butter of Jive Data Tiles. You can create a simple list of items for internal or external elements. With Jive Derby, we use the List Tile to show Jive people and instead of showing traditional Title and Company, we are padding the list with their fastest race times and number of races per racer. This is a great way for the leaderboard to be displayed in a compact space. There is also a link provided at the bottom "View Full Leaderboard" of the list to view the full leaderboard results, which is an example of a Tile Action link to a standard URL, in this case, a Jive document. (see: Figure 2).
Table Tile (Race Stats)
Simple Stream Integration
Embedded into the Jive Derby is a mechanism for developers to tap into the result feed and have Jive Derby notify a custom end-point with race results information shortly after the race. This feature was designed to give developers an interactive feed that they could use to build features like a simple stream integration, or power input into a more full featured activity based integration.
Developers attending JiveWorld17 are encouraged to get creative and showcase their SSI integrations using during the Hackathon and breaks in the Hacker Lounge and/or create a blog post in the Jive Jive Developers space. Talk with a Hacker Lounge assistant if you have further questions.
How to Register Your Simple Stream Client with Jive Derby
Note: If an end-point fails more than 3 times, it will be removed from the list. You will need to re-register your end-point to re-activate it.
The Jive Derby cloud environment was designed to work in a cloud environment, specifically Amazon AWS.
That being said, Jive Derby can be run in any cloud (or private) environment, as long as the functional requirements are met!
AWS EC2/ElasticBeanStalk w/AWS Certificate Manager
Manages / scales the Cloud Service as it receives information from the Local Environment and renders the Jive integration experiences.
Note: Cheaper alternative for this could be using NGROK for the Cloud Environment service.
AWS RDS - Postgres 9.6
The persistence layer for Jive Derby is designed to operate using a traditional SQL, as opposed to document databases like Mongo.
The primary function for AWS IoT is to aggregate all the data from the Raspberry Pi and Thunderboard into a web addressable service that would allow us to decouple access to the IoT devices from their most recent values. The Raspberry Pi is configured to poll these sensors on a regular schedule and submit the information to an AWS IoT shadow device, such that reading from AWS IoT we have environment details within recent history.
Note: Cheaper alternative for this could be to create your own cache service; however, AWS IoT has a lot of cool features for mass IoT device management, so if you can afford to have it as part of your architecture (or similar cloud management solutions), it may benefit you in the long run.
Lambda is not used as extensively as it could be in the solution; however, there is plenty of room for its use. Currently the only real-world application it has is to service a simple Alexa powered integration to read leaderboard results (and future idea to even to do lane assignments and race starts using an Amazon Echo/dot).
The Jive Derby local environment represents all the sensors and hardware needed to collect the race details.
Raspberry Pi 3 (Adafruit)
Electronic Derby Timer w/Solenoid (Derby Magic)
TODO: DESCRIBE WHAT IT DOES
Raspberry Pi Camera Board v2 - 8 Megapixels (Adafruit)
TODO: CONNECTED TO SPECIFIC RASPI PINS WITH BUILT IN PULL UP RESISTORS
TODO: raspicam, GraphicsMagick, ImageMagick (see README file) LINK
Pi Traffic Light (Amazon)
Provides a physical visual queue for various status during the Derby. Also, goes well with the concept of racing, as we use it to simulate a race tree!
IR Break Beam Sensor - 5mm LEDs x 2 (Adafruit)
Places alongside the track to capture race splits for various distances. (optional)
Thunderboard Sense (Silicon Labs)
Connect to a Thunderboard Sense, poll device for measurement updates, and then proxy those to AWS IoT.