10 Replies Latest reply on Mar 26, 2013 8:16 PM by mark.weitzel

    Jive Application Gateway Questions

    jtullo
    jtullo Dec 31, 2012 6:02 PM
      1. i am not clear on the reasons for needing access to a jive app gateway.  It's talked about in "Using OAuth in your appl" as an essential piece of both 2 and 3 legged OAuth and in "Jive Apps - Jive Application Gateway API" , it's purpose seems to be for pushing activity and updates to the jive instance when an app is not running.  Does that mean if you don't need the Jive Application Gateway for the 2nd reason but you do want to use OAuth (even if it's only for Jive for Office and Outlook plugin at first) , that you absolutely have to open up bi-directional comm to the jive app gateway at the JDC ?
      2. Are there plans to make the app gateway deployable on-premise ?
      3. What are the requirements/configuration options for allowing bi-directional communication between the jive app gw (at the Jive Data Ctr) and an on-premise app home server for a on-prem jive instance ?

       

      @karl_cyr

      Nimi Berman

      Israel Heskiel

      Noel White

      Kate Goodyear

      Mark Weitzel

        • Re: Jive Application Gateway Questions
          mark.weitzel Jan 3, 2013 5:51 AM (in response to jtullo)

          The app gateway serves a couple of functions. First, for applications that are integrating into Jive that may be deployed across multiple instances, it simplifies credential management. Specifically, one key/secret is provided to the app and will work across all jive instance. So, when an app does an osapi call and requests it to be signed, it will pass through the gateway.  Also, as you point out, this also allows activities to be posted back to Jive asynchronously. In 6.0, we have the V3 API, this has much more coverage and you can now do things like post an activity via REST directly. However, the catch is that you currently need to use basic auth (as compared to OAuth that the gateway uses).

           

          There are no plans to make the gateway on-prem.

           

          The requirements for communication are as simply that the jive instance has visibility to the gateway IP address. Technically, the app's home server posts an activity, this gets places in a queue. Then the jive instance periodically polls the gateway. This way, there are no ports on the firewall that need to be opened.

          • Re: Jive Application Gateway Questions
            millerkb@gmail.com Mar 22, 2013 10:11 AM (in response to jtullo)

            The Application Gateway is a bit confusing to me as well. I have been attempting to create a Jive application using v3 of the core api and rest api, and I'd like to post Activities to users on behalf of the app through the rest API.

             

            What isn't clear in the documentation is if you are sending an Activity to a list of users, do you just need the username/pass for only one of those users to pass for basic auth, or do you need an admin's credentials? In my testing, when using my credentials to post an Activity to 3 different people (myself being one of them), all 3 people get an email from Jive saying they have a new Activity, but I'm the only one who actually sees that Activity show up inside Jive (we are using the cloud offering right now). Furthermore, the activity says "via Inbound Activity Service" instead of being from my application.

             

            When I post an Activity to the same 3 people via the javascript core api from within the app, all 3 people see the Activity inside Jive and they all show as "via <app name>".

             

            I've seen the Application Gateway in several different documents, but nothing in the official v3 API documentation. Would really appreciate if someone could give me some pointers. Thanks!

             

            Ryan Rutan

            Mark Weitzel

              • Re: Jive Application Gateway Questions
                mark.weitzel Mar 26, 2013 8:16 PM (in response to millerkb@gmail.com)

                There are several use cases that we are talking about here, all of which deal with posting an activity to the stream.

                 

                Use case #1: An APP posts an activity to the stream on behalf of a user

                In this use case, the activity is posted through the gateway. There is a link to the application in the incoming activity and the user, on behalf of which the activity is being posted, MUST have the app installed.

                acitivity_via_gateway-2.png

                 

                Use case #2: Posting an activity via the JavaScript API

                In this use case, the osapi is called directly from the app. For all intent and purposes, it looks like any activity that comes in via an app. Here's one from the code runner.

                activity_via_jsapi-2.png

                 

                In both of the above use cases, notice there is the app icon in overlaid on top of the the user's avatar. This is an indication that this was posted via an app. Also, there's the "via <app name>" in the footer. Also, NO USER CREDENTIALS were supplied. Posting via the gateway leverages the OAuth key/secret that was provided to the app. Posting via the osapi means the user is in the application itself in Jive, so you know who it is.

                 

                Use case #3: Use the V3 REST API

                In the V3 API, you can now post activities using REST. This is done with basic auth and requires the user credentials. It will look like any other activity entry that is the result of behavior in the system.

                 

                 

                I hope this clarifies some of the confusion. I'll try to find time to update the docs accordingly and appreciate your indulgence.