Skip navigation

In this post I am going to show you how to create a public cloud service, have it deployed on Heroku, and then have it pushing data into a Purposeful Place on a cloud Jiveon instance. This should be of interest for any one wanting to build middleware for cloud customers.


Install nodejs, npm, and git onto your system.

See Getting Started > Installing the Jive SDK for instructions on installing nodejs and npm onto your operating system.

See Set Up Git · GitHub Help on installing git for our operating system.


Sign up for a free Heroku account.

Heroku is where we'll host your cloud service. Its super easy to use, and free to try!

  1. Sign up for a free account: Heroku | Sign up
  2. Install the Heroku toolbelt: Heroku Toolbelt


Sign up for a free Mongo Labs account.

Mongo Labs hosts the database for your cloud service. It is also super easy to use, and free to try!

  1. Sign up for a free account: Create Account | MongoLab
  2. Create a development (single/node) instance, and take note of the database connection string.


Generate your cloud service.

In a local directory, generate your cloud service in preparation for deployment to Heroku.


Create a local service directory

mkdir myservice
cd myservice


Create a skeleton service from an example:

jive-sdk create list


Update the dependencies package.json file to include mongodb (add jive-persistence-mongo):

    "name": "myservice",
    "dependencies": {
        "jive-persistence-mongo": "*"


Configure the service

Edit jiveclientconfiguration.json to configure your service.

Make sure to replace <<<DATABASE CONNECTION STRING>>> with the database url you got from mongolabs for your development database.

    "clientUrl": "http://localhost",
    "clientUrlExcludesPort" : "true",
    "port": "8090",
    "persistence" : "jive-persistence-mongo",
    "databaseUrl" : "<<<DATABASE CONNECTION STRING>>>",
    "extensionInfo" : {
        "name" : "My cloud service"


Deploy your cloud service.


Login to heroku using the Heroku toolbelt

heroku login

Tell Heroku that you want to run the node app

Create a file called Procfile with these contents:

web: node app.js

Store your service in git so Heroku can read it

git init
git add . 
git commit -m "init"

Tell Heroku to create your service

heroku create

Heroku will create the app, and tell you what its public address is, for example:

Edit jiveclientconfiguration.json again, and change the clientUrl parameter to be the public address of your app:

    "clientUrl": "",

Commit your change to jiveclientconfiguration.json:

git add jiveclientconfiguration.json
git commit -m'configured'

Tell Heroku to deploy your service

git push heroku master

Sanity test the service to see if its working

Navigate to http://<YOUR SERVICE ADDRESS>/samplelist/configure. If that comes up with a blue configuration screen, then its working!

Add your service to a Jive Cloud Instance.

Generate your addon

Install the service dependencies:

npm install


Generate the addon

jive-sdk createExtension


This will produce an file that will contain metadata about your addon, for upload into a jive cloud instance.

Upload your addon to a cloud instance

  1. Log into your jiveon cloud instance as a community manager.
  2. Go to the addons page and upload your

Create a social group and install the addon tile

  1. Create a social group
  2. Add the samplelist tile to your group, and configure it. You can type in any number in the counter field.
  3. Save the social group.


In a few seconds, the tile will start showing an incrementing counter. This means your service is up and running in the cloud on Heroku, and pushing data to Jive! I am super interested in knowing what hiccups you encounter when trying this, please drop me comments on your experience. is no longer available. Please use a similar service Cloud9 - Your development environment, in the cloud OR our recommended local development tool To use Ngrok, we have written the following guides:


We get many comments in the Jive Community from developers who want to play around with our Jive Node SDK and the Jive Developer Sandbox. The Jive Node SDK is an extremely fast way to learn what you can do with the Jive development platform; the Jive Developer Sandbox is a great testbed for what you create. Using these development tools and services, you can start creating apps and tiles for your Jive community in minutes.


The problem is that many developers' systems are behind firewalls or simply not routable from the Jive Developer Sandbox.


In order to work with our Jive Developer Sandbox, you need a publicly routable IP address with firewall policies that allow our server to communicate with your service. But if that is not a feasible scenario, there are other solutions. For one, you can move your development into the cloud.


We've already discussed how to use Heroku to communicate with our sandbox, but today we'd like to show you a simple solution that is particularly well-suited for rapid development (and can ultimately be deployed to Heroku for production, if you choose to go that route).


It involves using a great, cloud-based IDE called Nitrous.IO.


With Nitrous.IO, you can quickly have publicly accessible servers running your Jive services.


I just posted a tutorial in the Jive Community explaining how to use Nitrous.IO to do Jive Node SDK development against the Jive Developer Sandbox:
Using Nitrous.IO with the Jive Node SDK.


With this tutorial, it should take under 20 minutes to have a tile running in the Jive Developer Sandbox — with your service running on a Nitrous.IO box.


There are more aspects to cloud development that we'll be discussing in the Jive Developer Community in the coming months, but this gives you an initial idea of the possibilities.

The purpose of this post is to create a reference on how to set up a server environment that helps support Jive Cloud app development.  In future posts, I may link back to this one to give people context for the environment that I'm working in.


Overview of what we'll be doing

- Create a new CentOS instance

- Create new non-root user with sudoer permissions

- Install prerequisite software/libraries

- Configure httpd

- Configure SSL

- Configure iptables


Once you're set up, this environment will help you to

- Use any server web app platform (ruby, Java, node, PHP, C#, etc.) - Note: For C#, IIS would be running on separate server

- Develop/debug from home or office

- Support UAT and production environments

- Exercise total control over firewall, routing, etc.



So, let's get started.

First thing we'll do is set up our server instance.  I always set up my server instances using some VM hosting service, like Rackspace or Amazon Web Services.  A good friend of mine (CTO of a web startup) just told me about a service called Digital Ocean.  They have a REALLY easy interface for creating new instances and they only use SSDs, so their disk IO performance is awesome.  They are inexpensive and their instances start up very quickly (less than a minute).  For simplicity, I'm going to walk you through the process of setting up a new instance using Digital Ocean, but you could really use any service you want.  After you get your instance set up, then we'll configure it.



Setting up a new CentOS instance on Digital Ocean

- Go to and sign up.

- You will receive an email to confirm your registration, click the link in it

- Next, you will need to set up payment - don't worry, it's cheap


- Add a credit card and you're ready to go

- Next, we'll create a "Droplet" - that's their term for VMs

- Click Droplets and then Create Droplet


- Next, you will set the hostname of your instance, the VM size, region, image type, and then create the "Droplet"


- Almost there...


- After the Droplet is created, check your email - they will send you the IP address of the new VM and the root user password (Note: there is also a way for you to create the VM using SSH keys instead of a root password.  In that case, follow the instructions to add the SSH keys and then you will have a new option when creating Droplets)



Configure your DNS

Now that you have your VM set up, you will need to create a DNS entry for it.  Here are some things to consider before you do this.  First of all, a little later, we're going to be setting up the server to support HTTPS.  I highly recommend that you just bite the bullet and set this up right.  Don't use self-signed certificates or anything like that.  Jive will barf on them (when doing webhooks callbacks, for instance) and will not provide much in the way of feedback to indicate what the problem is.  So set this stuff up right from the beginning and things will go much more smoothly.


I use GoDaddy to manage my domain and DNS.  You will need to do what you have to do to get this set up depending on your environment.  (This may require coordinating with your IT department - good luck with that.)


Add an "A" record that points the hostname that you entered when you created the Droplet (or other VM) to the IP address bound to the instance.  When you have finished this, you should be able to ping your instance by its host name.



Configure your instance

I do my development on a Mac, so I just use the terminal window to SSH into my new instance.  If you are on a PC, you'll use Putty or Cygwin (or whatever) to log in.  If you use Putty and you created your instance using SSH keys, you may have a little more work to convert your private key over the the format that Putty likes. Google it.  (Note to all you hackers: you can also configure Putty to use your instance as a proxy to get through your IT department's overly-restrictive firewall.  Shhhh, don't tell!)


Okay, so get a terminal window up and running and SSH into your new instance:


> ssh


You'll be prompted for your password - it came in the email.  (If you set everything up to use SSH keys, then I assume you know what you're doing and can use your key to log in.)



Create Non-root User

First, we'll add a new user, add them to the root group, change their password, and add them to the sudoers list.  (Note: I use vi, you can use emacs or nano or whatever you want)


> useradd myusername

> usermod -g root myusername

> passwd myusername


> vi /etc/sudoers


Look for a line in the file that looks like this:


root    ALL=(ALL)       ALL


Duplicate the line, adding the user that you just created:


root    ALL=(ALL)       ALL

myusername    ALL=(ALL)       ALL


Save the file (:w!) and exit (:q)


Now that your new user is created, exit your SSH session and log back in as that new user.  This is to save you from yourself.  I have actually accidentally deleted my root directory as the root user before.  It was a very bad thing to do.


> ssh



Install Prerequisites


> sudo yum update

> sudo yum install httpd

> sudo yum install mod_ssl openssl

> sudo yum install lsof

> sudo yum install git

> sudo yum install wget


httpd is your Apache web server.  mod_ssl and openssl are used to set up Apache (httpd) to receive requests over HTTPS.


Now that httpd is installed, we'll set it up so that it launches automatically as a service any time you restart the instance.  Finally, we'll start the service.


> sudo chkconfig --add httpd

> sudo chkconfig --levels 2345 httpd on

> sudo service httpd start


Update your software firewall (iptables)


Depending on the service/image that you used to create your VM, the default CentOS firewall may be either totally open or totally closed (only accepting SSH connections on port 22).  The following is the configuration that I use.  I am by no means a Linux expert, so if someone is and you want to offer any advice on a better way to configure iptables, let me know.


> sudo vi /etc/sysconfig/iptables


Delete (or comment out) what's already there and add this instead:






-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

-A INPUT -p icmp -j ACCEPT

-A INPUT -i lo -j ACCEPT

-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 22 -j ACCEPT

-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 443 -j ACCEPT

-A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 80 -j ACCEPT

-A INPUT -j REJECT --reject-with icmp-host-prohibited

-A FORWARD -j REJECT --reject-with icmp-host-prohibited



Save the file (:w!) and exit (:q)


After updating the iptables configuration, you'll need to restart the iptables service.


> sudo service iptables restart


At this point, you should actually be able to make HTTP requests to your server.  If you want to see all the ports that it's currently listening on:


> sudo lsof -i -P


You should see that your sshd service is listening on port 22 and that httpd has a whole bunch of threads listening on ports 80 and 443.


If you navigate to your new server from a browser, you should see this page:





Getting an SSL certificate and setting up Apache to support HTTPS

For better or worse, I prefer to use a "wildcard" certificate.  They cost a little more, but I can put a wildcard certificate on any instance on the same domain, like,, etc. If that's not something you can do because of your IT policies, then just get a certificate for the hostname you specified earlier.  Like I said before, I use GoDaddy, and it was really easy to get my SSL certificate.  The first time I did it, I think the whole process took about half an hour.  Follow the instructions of the provider that is going to be issuing the certificate.  Once you have done all that, you should have the following three files.


1.  The SSL certificate itself (e.g. 18237563ksdjfh374.crt)

2.  The key file used to sign the certificate signing request (CSR) that you sent to the certificate provider  (e.g. myprivatekey.key)

3.  The SSL certificate chain file (e.g. ga_bundle.crt)


Make all of these files owned by and only read/write for the root user.


> sudo chown root:root mycertificatefile.crt

> sudo chown root:root myprivatekey.key

> sudo chown root:root gd_bundle.crt

> sudo chmod 600 mycertificatefile.crt

> sudo chmod 600 myprivatekey.key

> sudo chmod 600 gd_bundle.crt


Next, copy the files where they need to go.


> sudo cp mycertificatefile.crt  /etc/pki/tls/certs

> sudo cp myprivatekey.key  /etc/pki/tls/private

> sudo cp gd_bundle.crt  /etc/pki/tls/certs

Modify Apache's SSL configuration file


> sudo vi /etc/httpd/conf.d/ssl.conf


Look for these three entries and update them accordingly:


#   Server Certificate:

SSLCertificateFile /etc/pki/tls/certs/mycertificatefile.crt


#   Server Private Key:

SSLCertificateKeyFile /etc/pki/tls/private/myprivatekey.key


#   Server Certificate Chain:

SSLCertificateChainFile /etc/pki/tls/certs/gd_bundle.crt


Save the file (:w!) and exit (:q)


Set the server name in the Apache config file (httpd.conf).  If you don't do this correctly, calls from Jive may fail and it's very hard to debug this.


> sudo vi /etc/httpd/conf/httpd.conf


Look for this line:




And add the following line after it (updating, obviously, with your host name)





Save the file (:w!) and exit (:q)


> sudo service httpd restart


You did it!  After you restart the httpd service, you should be able to make requests to your server over HTTPS.  Double-check that it works in a browser.  Also in the browser, click the lock icon next to the https:// and make sure everything looks okay with the certificate.



Configuring Apache httpd to be a reverse proxy

This is really where the rubber meets the road.  We are going to use httpd to handle all the SSL stuff and forward requests coming into our server to go wherever we want them to.  For instance, we could have URLs that match a certain pattern go to our UAT or production app instances, or get forwarded right to our desktop computers at work or home.  This is REALLY, REALLY helpful for debugging any problems that might arise.


When you create Jive add-ons, you are going to specify a service_url property in the meta.json file.  This is the base URL that Jive will use for all communication with your app or service.  Since that URL can change for dev, production or UAT environments, I usually create Maven profiles (you could too if you are using Maven to build your project) to specify the different environments I'm using.  During the build process, I will use the maven-antrun-plugin to set the various properties of my meta.json file, depending on my profile.  I'll talk more about that in a future post.


Okay so let's say you have four different endpoints, your production app, your UAT app, and your work dev computer and your home dev computer.  I'll assume for a second, that you are running a Java-based app, hosted in Tomcat for your production and UAT environments, and for development, you are running a debugging session in IntelliJ or Eclipse at work or home.


We want the following routing rules:  ->  http://localhost:8080/my-cool-app-prod-v1.0.1  ->  http://localhost:8080/my-cool-app-test-v1.0.1  ->  (this is going straight to my dev computer at work)  ->  (this is going straight to my dev computer at home)


> sudo vi /etc/httpd/conf/httpd.conf


Look for a line like this:


#<IfModule mod_proxy.c>


Uncomment that line and put your mappings below it, like this:


<IfModule mod_proxy.c>

# production

ProxyPass /my-cool-app http://localhost:8080/my-cool-app

ProxyPassReverse /my-cool-app http://localhost:8080/my-cool-app



ProxyPass /my-cool-app-test http://localhost:8080/my-cool-app-test

ProxyPassReverse /my-cool-app-test http://localhost:8080/my-cool-app-test

#  Uncomment mapping below to direct traffic from UAT site to your dev machine

#  This is useful for when you want to attach a debugger to the running web app

#ProxyPass /my-cool-app-test

#ProxyPassReverse /my-cool-app-test

# dev

ProxyPass /my-cool-app-dev

ProxyPassReverse /my-cool-app-dev


# home

ProxyPass /my-cool-app-home

ProxyPassReverse /my-cool-app-home

Save the file (:w!) and exit (:q) and then restart the httpd service.


> sudo service httpd restart



That's all there is to it.  Once you've done this once or twice (assuming to are using a wildcard certificate), you should be able to get a new server instance up and running in about 10 or 15 minutes.  I have found this to be a very handy way to do development for apps running on Jive Cloud instances.  Maybe someone else will find this helpful as well.



Thank you to everyone who took the time to register and/or attend today's webinar!  In total, we had over 200+ people register, and 150+ attend.  So it's a great 1st start!  Special thanks to my fellow panelists yuval.z and aron.racho, and we look forward to our next Webinar, which should be sometime in Mid-Late/September.

JiveWorld14 - The Jive Developer Mecca

When:  October 21-23, 2014

Where:  Cosmopolitan - Las Vegas, NV

  • More Sessions
  • More Hacking
  • More Beer

Register Today to Get Your Early-Bird Discount


Q2-2014 Jive Developer Webinar Materials

Below you will find links to the recording along with questions and feedback obtained during the webinar. 
Attached you will find slides from today's presentation.


For any questions about today's Webinar, you can use the comments (below) or post a question in the Jive Developers community.

Screen Shot 2014-06-12 at 4.27.47 PM.png

Click here to play/download the WebEx Recording



The following are the polls associated with the Q2 2014 Jive Developer Webinar:



The following were questions asked during the webinar:

  • baronzemm "positive note. getting started content is extremely useful for those of us that work in tons of different platforms. Meaning we might only do some jive dev 2-3 times a year and need to regularly refer to the starter docs."
    • A:  Absolutely!  In addition to refresher courses, we are hoping to ramp up more people easier to increase the number of skilled eyes to read and possibly respond to questions.
  • dreiswig "YAY!" In response to our new APIs that allow you to backdate publish and update dates. (a.k.a Data Migration API) =)
  • sreenathg "Do you have any documentation on Analytics API?"
    • A:  Analytics - Developer Resources will be the best place to start.  Documentation is admittedly lean at the moment, but should be enough to get you started.  Feel free to ask questions in the community for any perceived gaps and we'll do our best to cover ASAP.
  • l9rezn - "Will Mor Avital be at JIVE World?, I feel like I'm the only girl "developer" - can there be wine for me?"
    • A: At the end of the day, mavital will be the one to best answer that question. =)  As for the wine, I'll ask around and see what we can do!  Will try to focus more on you not being the only "girl developer" at the hackathon =)
  • whoiskevin -   Any plans to document methods of integrating web services with SSO implementations?  Custom tokens for instance.
    • A: Noted.  yuval.z and myself will take this to the drawing board and see what we can put together in our coming sprints.
  • Lsparks - "Maybe I missed it, but have any updates been made to app action contribution points in regards to applying permissions?"
    • A:  At this time, there are no app action contributions in the Admin Permissions screen.  The closest we have is the Place Settings Extension point that lets you tuck an App Experience behind the "Place" > Settings experience for Admins.
  • drice75 - "I need to connect Jive with SharePoint.  Where do I start?"
  • cgum - Any possibility for reducing padding around window that hosts an app, specifically the canvas view?
    • A: Logged as JIVE-45414
  • cgum - What's the best way to integrate 3rd party app content into spotlight search?  Like, if I create something in my app, I want it to show up in spotlight search.
    • A:  Either use ESF to do your document integration, such that the ESF framework will manage the content metadata into the search index, or use the External Objects w/Activity where the activity entries are indexed and appear in spotlight.  Alternatively, if you didn't want spotlight, you might be able to use the OpenSearch feature; however, results are returned out of context (meaning the same for everyone).
  • pcrownov - "I am assuming the OAuth revoke is for Mobile auth. Is it possible to grant OAuth tokens for API access to specific users via the API to bypass things such as SAML?"
    • A: API definitely allows you to create OAuth tokens, the outstanding question her is whether or not an instance bound to SAML will still require SAML authentication.  Not sure of the AuthProvider precedence here.  Asking internally.

Filter Blog

By date: By tag: