Common Jive Add-On Use-Case Patterns

Document created by Ryan Rutan on Feb 24, 2014Last modified by Ryan Rutan on Jun 1, 2016
Version 10Show Document
  • View in full screen mode


The following is a document that is meant to capture middleware patterns for common scenarios in an enterprise environment.  It is broken into 2 main sections: Non-middleware and Middleware.  For some more details about the Jive Platform and general add-on development, check out Jive Platform - Developer Resources


Non-Middleware Patterns


OAuth2 API Client



This pattern is the fundamental way for doing a straight Jive API integration.  Following this pattern, will result in your external service being able to obtain OAuth2 tokens from Jive on behalf of any authenticated User.

Using OAuth2 virtually insures that solutions will work across all Jive instances, regardless of SSO configurations.

Jive supports both 2-legged AND 3-legged OAuth Flows, including password and code grant_types.


Simple Stream Integration

New This is a very powerful and simple integration pattern that you can build and deploy in minutes!   See the Simple Stream Integration blog series (resources below) to see how you can get exponential return with this pattern / progression!



This pattern is a very powerful way to get activity and content into Jive with minimal effort.  Built on a webhook design principle, Simple Stream Integrations create a Jive URL where external systems/processes can HTTP POST data that is then processed by the xform.js transformation file into the native Jive Activity Dialect.


When the Activity Tile is installed by a User to a Place, the URL creates a revokable OAuth token on behalf of the installing admin and embeds it into the URL, which reduces the need for additional HTTP header management.

Content created by this pattern (Title/Body) is indexable by Jive, and has it's own distinct Jive URL & API Content ID.  Content created using this pattern also has native UI/API support for Commenting, Liking, Sharing, Booking and Structured Outcomes.




Analytics (Data Export) Client



This pattern shows how to connect a standard external service/client to the Jive Analytics API.


Once a clientId/clientSecret have been setup for access, processes exchange these for an access token that lasts up to 30 minutes before it needs to be refreshed.


Jive Analytics covers the entire Jive instance, as such, connecting to Analytics operates as Full Access permissions.


Processes that require additional activity detail not provided in analytics meta-data will need to call the Jive REST API.  It is recommended that services use an OAuth2 API Client to do so (see above).

Note:  This pattern assumes that your Jive instance is either Jive Cloud or has been connected to Jive Cloud Analytics services.




Custom View Tiles & HTML Tiles



This pattern is about injecting user experiences into Jive in a modular way via Tile Pages.  The only difference between a Custom View and HTML Tile is that a Custom View Tile uses the OpenSocial framework to invoke service calls to get additional contextual data.  An HTML Tile is a simply a set of HTML that is packaged into a Tile for display.


Due to page-load performance considerations, Jive limits the use of Custom View Tiles (2 per Tile Page); however, imposes no limit on HTML Tiles.  This limitation is configurable via a Jive Support Request to gauge traffic/capacity of the Jive instance to support increases to the setting.




Jive Hosted Apps



This pattern brings all the power of Jive App and Add-on development, but without the excess baggage of standing up a middleware service.  Simply bundle all your app assets and artifacts into the Jive Add-On and use the local Jive as your hosting service.  It's that simple!


Jive Apps are a great way to bring new user experiences into Jive that expose capabilities to remote systems.  Even better, they are built using straight forward technologies, such as HTML, JS, CSS and REST services.

Note:  Jive's OpenSocial services invoke the external service, not the client browser.   This means that services (if needed) can be protected behind firewalls where only the Jive servers can access.




Jive Hosted Apps w/Jive Connects



This pattern increases the capabilities of the Jive Hosted Apps by adding a built-in service managed in Jive that securely stores the most commonly needed pieces of information for service integrations, which are Identity and Access Tokens.


Jive Connects acts as a secure proxy between your client-side app and a protected service.  When calling a service that requires authentication/authorization, Jive Connects offers a framework for apps to securely capture appropriate authorizations and store them for future service calls made by matching users.  If at any time the stored credentials become invalid, Jive Connects framework prompts apps to recapture credentials.

Jive Connect currently supports the following API authorization flows:  Anonymous, HTTP Basic, API Key, API Key + HTTP Basic and OAuth 2.0.




Simple Stream Integration w/Jive Hosted App (Jive Connects optional)

Continued Now that you've created your Simple Stream Integration in minutes (see above), you can work through simple progressions (minutes / hours) to add even more power to this pattern.  Definitely check out the Simple Stream Integration blog series (resources below) to understand the full power of this pairing.



This pattern is a continuation of the Simple Stream Integration pattern above.  What makes this most intriguing, is that when the SSI creates the External Object Content, you can swap out the body of that content to be a Jive App view that is hosted from within the add-on.  Since the Ext Object has it's own contextual data, you can use this information to seed the app experience to some exceptional things.


With access to Jive Apps, and subsequently Jive Connects, developers can enhance the user experience around the activity content from a simple read experience to a fully immersive read-write experience (if needed).  Perhaps the invoking service didn't pass a lot of detail? Or perhaps you want to provide a quick feedback loop to the source system?  These are both possible (and MUCH MUCH MORE) using this pattern.




Jive Anywhere Cartridge



This pattern covers extending Jive onto third-party websites using Jive Anywhere and custom cartridges.  Jive Anywhere is a browser plugin that operates in all the major browsers, including: IE, Firefox, Chrome and Safari.  Cartridges are definitions for custom behavior to be invoked (or made available) when a user is viewing specific third-party websites.  The true power for Jive Anywhere comes from the fact that it includes an authenticated Jive connection capable of calling Jive REST API for additional context (as needed)


Two powerful use-cases:

  • Effortlessly start meaningful discussions in Jive about third-party website content with a click of a button.
  • Enrich third-party website experiences by injecting Jive content (personalized to the viewer) into the third-party website experience via DOM injection with jQuery.




Middleware Patterns


Platform Options


The Jive iPaaS SDK allows developers to quickly create beautiful integrations to your Jive instance. With the SDK, you don't need to worry about middleware, as we will host the integration in the cloud for you. You also don't need to think about the Jive core API's, as all the communication to Jive is done by the SDK.


Did we mention that the SDK projects are written using Java?


To give the Jive iPaaS a try, check out Flow is a cross-service iPaaS that can integrate multiple platform services from multiple platform processes together into a clear integration path.  It currently supports best of breed enterprise technologies, such as Salesforce, Marketo, Slack, Google Apps, OneNote, Evernote and more.


For a list of integrated platforms, click here.

Note: Flow is a third-party service, and will require users to register with their service.  This service has a FREE trial, but does have charges for production use.

To give Flow a try, check out:

Jive add-ons can be built using any web-ready programming language.  To illustrate this point, we have assembled a series of open-source SDKs to demonstrate the necessary capabilities in each language.  Need help building add-ons in an incomplete SDK?  Reach out to Ryan Rutan to inquire about Jive's SDK Your Way initiative.


Pick Your Language and Get Started!

Dont forget to check out services like Ngrok: Warp Speed for Your Integration Iterations to help expedite your Jive development process.

Note:  Any of these middleware platform options can be coupled with "non-middleware" patterns that are embedded into the Jive add-on.  To do so, will probably require manually packaging your Jive add-on, as current tooling may not properly set references to local and remote assets correctly, but this is a gap in tooling, not a platform limitation.  Let us know which use-cases you are trying to use that are not supported well by our tooling and we'll do our best to rectify the situation, where possible.

Standard Service Proxy



This pattern is a very standard use of middleware.  Requests from a Jive App, Tile or Webhook trigger a call to a remote system that has a matching user profile.  The middleware service is responsible for authenticating the calling user and mapping them to a trust context in the external system.


In this example, the middleware uses the Jive Signed Request mechanism to validate request authenticity and determine Jive tenantId and User details.  These details are mapped to an external service account, which was authorized usually during the App / Tile configuration stage.

Note:  This pattern can also support the OAuth2 API Client pattern.  (see above)


If you have questions about this pattern, feel free to post a question in the Jive Developers  community and we can share more details around your specific use-case.


Tile Data Proxy



This pattern covers the standard Tile data update process.  Usually, in a Tile configuration interface, the user will map the Tile Instance to a construct in an external system.  When an event fires in the external system, it will notify the middleware service, which translates/articulates the data into the appropriate Jive Tile Style and pushes the data to the mapped URL.


Once the data is pushed, Jive retains a copy of the data for display purposes until a new set of data is pushed into the Tile Data Push URL.



Externally Hosted Jive Apps / Custom View Tiles



This pattern focuses on the values of hosting a Jive App external to Jive.  If there is already an existing infrastructure hosting resources, this tends to be an easier call, but there are other benefits.


When bundling an app into an add-on, you are limited to static resources.  When OpenSocial makes a request for an HTML view, JS, CSS, image etc... it doesn't care how it's rendered.  This means that it is possible to user server-side scripting technologies to dynamically render components of the app.xml, JS, CSS and images to obtain additional capabilities using the Jive Signed Request headers.

Note:  For performance reasons, Jive caches requests to app.xml and many of the HTML views.  As such, any dynamic elements rendered may end-up cached in Jive.   In most cases, the add-on will need to be removed to uncache the resources.



WebHook Bi-Directional Sync

This pattern is very generic and highly re-usable  It covers concepts such as bi-directional Activity Streams and Content synchronization, as well as any general event pub/sub scerario.



This pattern focuses on the concept of having at-least 1 system that wants to be kept in-sync with another (or in some cases, bi-directional syncing).  Since Webhooks in Jive require OAuth, a user must "authorize" the syncing to happen on their behalf.  This is usually done via an App or Tile configuration screen.  Once the authorization is complete, the middleware service holds onto the accessToken and waits for events to come to the defined callback URL.


As with other middleware solutions, the middleware components acts as a broker/translator (as needed) to insure that each side can send information off to other systems as easy as possible.



External Storage Framework (Bi-Directional)

Due to this pattern's detailed implementation requirements, we strongly recommend the use of the Jive iPaaS to simplify building and deployment of any custom storage providers.



This pattern addresses the concept that files are a universal collaboration medium, and often proliferated throughout various systems.  The External Storage Framework provides a means for Jive to act as either a client or server for binary file content, and synchronize them with an external service.  In addition to the binary content, ESF also supports synchronization of common collaboration paradigms, such as "Likes" and "Comments".


It is recommended that you check Jive's out-of-the-box external storage integrations before building your own; however, definitely reach out to Yuval Twig if you have any questions about those offerings.


To get started with this pattern, we recommend starting with the Jive iPaaS!