17 Replies Latest reply on Mar 24, 2014 8:34 PM by whoiskevin

    Preferred way to customize?

    ben.duffin86

      What is the preferred way to customize an instance of Jive SBS these days?  It used to be plugins, but I feel like folks might be moving away from that.  Perhaps a multi-module overlay is the way to go?  And how do add-ons compare to plugins?

        • Re: Preferred way to customize?

          I would definitely check out this session from JiveWorld13 with Aron Racho and Mark Weitzel

          Jive IS your enterprise development platform!

           

          Add-ons interact at a service-level with predefined hooks into the Jive UI and event model.  Since plugins have more or less direct access to the inner workings of Jive, there are obviously some gaps; however, our project team has done a lot to make sure that developers have their hands full of options when it comes to building solutions that have been proven to add value.

           

          Let us know your thoughts or what you are considering, and we'll be happy to help answer any questions here in the JC. =)

            • Re: Preferred way to customize?
              aron.racho

              +1 using addon strategy for customization is more upgrade friendly than plugins as well. A good way to sample our integration offerings is to try them through the jive-sdk. You can use this framework to extend the UIs through jive apps; listen (and respond) to system events using webhooks; create services for pushing activity and tile data into jive; create an external storage provider; etc.. Of course you can also do amazing stuff with our V3 REST APIs!

                • Re: Preferred way to customize?
                  whoiskevin

                  I still face a barrier to using the Add-ons and Apps strategy.  Enterprise desire to have zero connectivity to the outside world.  So we can all debate those pros and cons till we are exhausted but the wall is real.

                   

                  Are Add-ons in Jive 7 still using a cloud service for me to deploy and use them?  I know apps had this limitation and it has made them useless to me.  If Add-ons face the same limitation then they too will not be an option.

                    • Re: Preferred way to customize?
                      ben.duffin86

                      This would also might be a barrier to my company, depending on how it is implemented.

                        • Re: Preferred way to customize?
                          ben.duffin86

                          Partly answering the question:  as an admin you can view an Add-Ons screen in the front-end (not admin) UI in Jive 7, by clicking on your avatar dropdown in the top right corner.  The Add-Ons screen allows the option to upload the ZIP of an add-on. Assuming these add-ons aren't meant to provide functionality which the user can choose to add (which isn't my use case- we'd apply all changes globally), then I don't think the cloud service is required.  I see references to a sandbox mode which would allow anyone to upload ZIPs- but an admin should be able to upload them in a production environment.

                        • Re: Preferred way to customize?

                          Kevin Brown - Apologies for the delay here.  Add-Ons are all service based, and do not require the cloud to work.  A zip file is uploaded into Jive that contains all the end-points for the Add-On registration process.  This gives you the ability to control and reference your services.  That being said, grabbing an Add-On from the Add-On Registry may be problematic, as most of those require access to an external service.

                           

                          In the original version of Apps, you are correct ... there was a dependency on the cloud.  Since the release of the DevConsole app (late Jive 5, early Jive 6), customers have been able to deploy apps internally without the need for cloud.  If your services require special authentication, you might need to use JiveConnects to fully insulate yourself; however, using custom built apps air-gapped is possible, and is even easier with the Add-On deployment model.

                           

                          Hope that helps answer your questions,

                          RR

                          1 person found this helpful
                            • Re: Preferred way to customize?

                              Just to be a bit more precise on Ryan's answer...

                              Add-ons that are in the GLOBAL add-on registry. When you go into J7 Add-ons menu, there's an option for "Available". That is when you point to the global registry. You can, of course, turn this off. And, as Ryan said, you can install add-ons that run completely within your infrastructure.

                              Screenshot_1_30_14_9_28_PM.png

                                • Re: Preferred way to customize?
                                  whoiskevin

                                  Sorry to late comment on the thread.

                                   

                                  The Global registry definitely isn't available.  But more important and limiting is that the "Add-ons" tab in the admin is completely unavailable.  It takes it nearly 10 minutes to timeout!   And the reason is because even clicking on it requires access to Jive servers.   Definitely a show stopper right now since not only at addons there but I believe the templates for creating groups.

                                   

                                  BTW I think that also means no developer console app.

                                    • Re: Preferred way to customize?

                                      Kevin Brown - Are you seeing this on a UAT/Production environment. I haven't personally tested the air-gapped element of Add-Ons yet, but yes the registry in the product requires a service to get the listing, but that listing should also be available here:

                                      http://www.jivesoftware.com/social-business-platform/add-ons/#view=list

                                       

                                      If you are running air-gapped, then all you will need to do is download the ZIP file for the desired Add-On and install it by uploading.  Unless I am understanding your scenario?  Could you confirm/deny my comprehension?

                                        • Re: Preferred way to customize?
                                          whoiskevin

                                          This is in my UAT and Dev environments.   I'm not trying to find an add-on.  But related to this discussion I've discovered that since machines in my environments will not be able to reach out or talk home (they are air-gapped) and what I see now is that we cannot even access the add-on tab of the admin console (/admin/apps-dashboard.jspa)  It eventually times out.  The add-on page for the user does seem to come up (/addon-services!input.jspa) and would probably allow me to upload a zip file of the addon I choose from my hard drive. 

                                           

                                          So there are other features on the add-on tab of the admin related to purposeful places I think as well as addons.  If it cannot work without connectivity as I see now then it seems there will be some issues for a secure environment.  If I use my local box install to access things I can probably work with an add-on from there but having the admin console completely time out and take 10 mins to do it is a big concern if there are other things under that tab that we might want to configure like the purposeful places.

                              • Re: Preferred way to customize?
                                ben.duffin86

                                A couple questions regarding add-ons:

                                -Can they contain custom Java code?

                                -Do they require node.js development?

                                -Are they commonly used by on-premise Jive instances?  Per Kevin's comment, it would be odd to have to go through an external service to provide functionality for our on-premise Jive instance.

                                -I'm still not completely sure what the capabilities are for add-ons.  Are add-ons used for much besides providing cartridges/tiles/other-pre-packaged-bits-of-functionality?  Let's say I want to make a series of external web service calls, execute some custom business logic, hit an external database, call a Jive API, then return a view to the user (a whole page or an embeddable chunk that I can drop on, say, the profile page, via the theme or some other hook)- is that possible?  If not, which parts would be be the problem?

                                  • Re: Preferred way to customize?
                                    pradeepgm

                                    +1, I do have similar questions.

                                     

                                    I think Ryan Rutan would be the best person to answer these questions.

                                    • Re: Preferred way to customize?

                                      Ben Duffin

                                      Add-Ons are completely service-based.  How you implement those services is up to you. We recommend the Jive SDK w/Node.js for the fastest results.  That being said, if you are asking if Add-Ons have the same level of Java access that plugins once had, then the answer is no. Add-Ons do not run in the container and as such, are not able to manipulate core Java natively.

                                       

                                      We just released a crude SDK that shows how you can implement some of the end-points using simple Java.  I'm actually working on a Jersey Reference implementation that I've started getting some good progress on.  But it shows that you can implement the end-points in whatever technology you are comfortable with; however, the road to solution is much faster using our Jive SDK w/Node.  I'm a Java guy, and I wanted to show others that it could be done, hence my side project.

                                       

                                      Add-Ons are used by any version of Jive (On-Prem or Cloud)

                                       

                                      As for you business logic use-case, you are definitely talking about Apps when you start bringing in custom UI elements.  Apps call services, and those service can be orchestrated to do whatever.  Does that help?

                                      1 person found this helpful
                                        • Re: Preferred way to customize?
                                          ben.duffin86

                                          Thanks Ryan, I'm definitely getting closer here.  So, the purpose of an add-on is to provide some sort of configuration that Jive uses to call web services which return data , and the add-on can contain an app which integrates that data into the UI somehow.  Am I correct so far?

                                           

                                          When you say that add-ons are service based (and that apps call services), where are those services expected to live?  From Aron's jive-sdk page, it seems that those services are running from a provider called Heroku.  Could we host our services on-premise?  Also, is there any documentation on the format that the add-on expects to use (URL structure, params, HTTP methods) when calling those services?  And how does the add-on expect the data to be formatted when it gets a response from the service?  It's cool that the jive-sdk does all this for you magically, but we need the details in order to figure out how it will work for us.

                                            • Re: Preferred way to customize?

                                              Introduction to Jive 7 Integrations in 5 Minutes - definitely give this video a look.  Short investment, but gives a good survey of all that is possible. 

                                               

                                              The Add-Ons are structured hooks in the product to either push/pull data in a structured means, and/or create an integrated/embedded experience in Jive.  In the video above, it talks about each of the integration points and why you should use them.

                                               

                                              Add-Ons are designed to be a middleware solution, so services can live where-ever as long as Jive can route to the middleware host, and vice-versa.  Services can be hosted anywhere, there are benefits of hosting on Heroku with Node JS (infrastructure, quick spin-up,etc...) but if you have the acumen/means, an end-point is just an end-point.  Bolded the above statement, as long as that holds true you are in a good place =)

                                               

                                              The Jive SDK takes care of the boiler-plate code, hand shakes, and most of the other niceties.  To your point, that level of documentation is scattered (and to be honest) incomplete at the moment.  We have a partner who has implemented these end-points in .NET, I'm on my way with Java + Jersey, and Node JS is the SDK.  It's not a black box, as the entire code base is Open Source but there are a lot of hand shakes ... so admittedly this is difficult.  I will be working with a doc writer soon to start diving into this level of documentation; however, emphasis has been on onboarding people as fast as possible ... which is primarily the SDK at the moment.

                                               

                                              Does this help?

                                              1 person found this helpful
                                                • Re: Preferred way to customize?
                                                  ben.duffin86

                                                  That makes sense.  So the data layer of the add-ons is pretty powerful, since you can create backing services which do pretty much anything.  The next question is how exactly we're able to use this data to alter the experience within the application.  Some of the videos have given a general idea of ways to do this (bang apps, tiles).  Are you able to make a custom theme which pulls data from an add-on?  And is there any documentation on what parts of the profile page can be altered using add-ons?