Skip navigation

headline.pngAs a member of the Jive Security Team, I am committed to keeping our customers safe from the latest threats. Part of the daily responsibilities of my team and I include reviewing reports generated by our security tools, including event loggers, the intrusion detection system, application scanners and network scanners. With all these tools in place, you could imagine that I would spend a significant amount of time logging into each tool every week, setting the report parameters, waiting for the reports to download, then uploading them into our internal Jive community, so that I could review and discuss the findings with my team. Obviously, this was a problematic time sink for my team and I, especially in a field where agility is key!

 

Being an Engineer, I knew there was only one solution to this problem: automation. I found inspiration in another team that had built an automated mechanism that reported application build statuses directly in the community. This is exactly what I needed for my tools: a seamless way to get information directly into Jive without any manual steps. What was their secret? The Jive API of course! A quick search of our documentation led me to the Jive REST Rest API v3.6 → Content service; using this service, it's possible to push files right into Jive, which fit my use case perfectly.

 

Now that I had my API hook, I just had to build an automation script around it. I decided to use Python as my language of choice, as its flexibility allowed me get the script written quickly and easily. The first step was to write methods for grabbing the report files out the various tools we use. I won't go into detail on that here, as the methods vary widely per tool (SSH, CURL, APIs, and email were all used). Then there was the small detail of architecture; this script needed to run somewhere, so I setup a virtual machine inside of our tools environment.

 

To give you a rough idea of the end architecture, here's a simple diagram:

Jiveservers.png

After that was complete, it was all just matter of hammering out the fine details of what I wanted to do with the reports in Jive.

 

That's where it all came down to one line of code:

os.popen("curl -u "+username+":"+password+" --form \"content={'parent':'"+communityURL+"/api/core/v3/places/"+placeID+"','content':{'type':'text/html','text':'<body>"+bodyText+"</body>'},'subject':'"+subjectText+"','type':'file','visibility':'place'};type=application/json\" -F 'file1=@"+filepath+";filename="+filename+"' '"+communityURL+"/api/core/v3/contents'")

 

So as you can see, I making a call to the system CURL to execute the REST call; one may argue that I should have used Python's native CURL library, but I went this route as it's easier to debug. The call is parameterized, making it highly reusable. Let's break down the key parts of this call:

  • -u "+username+":"+password+" - The credentials being passed for authentication. We created a new a "security reports" user in our community specifically for this script. As as security guru, I must remind you not to store credentials in the script, but rather, put them in a separate, read protected location.
  • 'parent':'"+communityURL+"/api/core/v3/places/"+placeID+"' - The place where the file should be posted. The placeID is the number that can be found in the URL of a group or space.
  • 'text':'<body>"+bodyText+"</body>' - The content that appears above the file preview in Jive. It can be optionally left blank.
  • 'subject':'"+subjectText+"' - The name of the document used in Jive. Note that it must be unique within the space, or else this call will fail.
  • 'type':'file' - Specifies the content type. In this case, we're using file, but can changed to create another type, such as a document.
  • 'visibility':'place' - Means that it will only be visible to people who can access the place where it's stored.
  • file1=@"+filepath+" - The path to the file within the local file system.
  • filename="+filename+" - The name of the file as it will appear when downloaded from Jive.
  • '"+communityURL+"/api/core/v3/contents' - The URL of the API service where the post is sent.

 

Now with the script ready to go, I promptly set up some CRON jobs to fire it every week. The jobs are separate for each tool, as each one has a slightly different schedule in regards to when new reports are available. Now at the scheduled time intervals, the reports appear in Jive!

 

Having our reports automatically uploaded has had several key benefits for our team:

  • Many of the files are too large for email, and would otherwise be very difficult to share.
  • Having them in Jive allows us to easily discuss them, link to them, search them, and bring in other teams when needed.
  • No more time is wasted waiting for report generation and download.
  • Jive serves as a redundant backup, and easy to access archive for these reports.
  • We can keep tighter controls on who can access our tools, since non-administrative users can view the data they need right in Jive.

 

While I have spotlighted only one potential use of this API capability, the possibilities are endless. One team within Jive use this to upload daily production monitoring data, while other team has designed an "org chart" user that posts whenever employees in the company join, leave, or are promoted. Such novel uses will help you and your company get the most out of the Jive platform, deriving extra value through minimal development work.

 

What do you think about this simple integration? 

How can you extend this example to meet your needs? 

Do you have any suggestions for improvement?

 

George Burri

Security Engineer

Jive Software

developer-resources.jpgSince the first day of my transition to Developer Evangelist, Mark Weitzel and I have agreed on many things, but nothing more than the fact that Jive needs clearer and more concise documentation for ALL it's integration offerings.  As we've sifted through the work, and aligned ourselves with a strategy and resources to execute, I wanted to take  a moment to share a bit about our documentation roadmap and direction over the coming months, and offer the opportunity for you to provide your thoughts.

 

Introducing Yuvi Z

Our first order of business in this journey was to lobby and sequester a dedicated tech writer resource, his name is Yuvi Zalkow ... but you can call him Yuvi Z.   Yuvi is new to Jive, but comes to us with an extensive background in programming and technical writing skills.  His primary focus in this project will be to champion a clear and consistent documentation experience that spans across all disciplines of Jive App / Add-On development.

 

He recently posted his first piece of content, Getting Started > Deploying a Jive Node SDK Project as an Add-On and has more in the works as we speak.  You might want to get to know Yuvi, you'll be seeing his name quite a bit in the community! =)

 

Introducing Developer Resources

Some of you may have noticed recently that I created a series of developer resource documents here in the Jive Developers community, such as:

 

ResourceDescription
Jive Platform - Developer ResourcesThe top-level developer resource, as well as platform integration concept introductions
Analytics - Developer ResourcesThe official developer resource for Analytics integration with Jive
Jive Apps (OpenSocial) - Developer ResourcesThe official developer resource for App integration with Jive
Cartridges (Jive Anywhere) - Developer ResourcesThe official developer resource for Cartridge integration with Jive
External Storage Framework - Developer ResourcesThe official developer resource for External Storage integration with Jive
Mobile SDK - Developer ResourcesThe official developer resource for Mobile integration with Jive
Producteev - Developer ResourcesThe official developer resource for Producteev integration with Jive
REST & Webhooks - Developer ResourcesThe official developer resource for REST/Webhook integration with Jive
Tiles, Templates & Streams - Developer ResourcesThe official developer resource for Tiles, Templates & Streams integration with Jive

 

As we progress in cleaning up and adding documentation, we plan to use this documentation structure as a means of organizing official content and direction per integration pattern and inter-weaving it in a meaningful way throughout the developer experience.

 

What's Next

As we move forward, we will continue to draw alignment between our developer community, documentation and the overall developer experience.  One way we plan to bring this all together is through 2013-14 Jive Developer Program.  Using the Jive community, along with other technologies, such as Marketo, SmarterPath, Bunchball, the Jive SDK and a redesigned developers.jivesoftware.com (currently in-progress), we plan to make it easier than ever to get educated on the latest Jive technologies and be rewarded for doing so. 

 

Stay tuned, and if you haven't check out any of the 2013-14 Jive Developer Program badges, such as:

... Don't miss out on a chance to get ahead of the game and win prizes and opportunities to speak at / attend JiveWorld14!

 

After we get a first pass of the getting started cleanup, we will look to community feedback (both past/present) to help us prioritize which content / examples to flesh out first.


  • What do you think of the current high-level direction?  Any concerns/questions that we can try to address?
  • If you could pick 1-3 topics/areas, what would you like to see improved/added to the documentation?

 

 

Filter Blog

By date: By tag: