Orchestrator and integration

[TheVMinator]

I need to make orchestrator talk to a number of third party products such as a CMDB, IPAM, DCHP and backup product during the provisioning process.  What is the best programming language to use? Assuming I am fluent or have people on my team fluent in java, python, vb.net, javascript, and ruby, what is the best language?

[iiliev]

Well, if you plan to build a vRO plug-in for some 3rd party product, the best languages would be Java and Javascript (for backend code and scripting code, respectively).

Another thing to consider is the runtime environment limitations. For example, using vb.net/c# will require ,NET which might be hard to deploy on non-Windows environment.

[TheVMinator]

In this case we are using the vCO appliance, not the Windows version of VCO.  (we will be using vrealize orchestrator 6.0 when it comes out to be exact).

To clarify - you said use javascript for scripting.  If I am using the appliance, is it a problem to try to use python?  How do javascript and python compare if I am trying to build a plug-in for a third party system for orchestrator to interact with it? 

[bencouture]

We integrate with applications from each of these categories. Some of the products we use have a REST or SOAP API, which we prefer to use when possible, so we use the REST and SOAP plugins in vCO for these. When a web API isn't available, we have to use whatever interface the vendor makes available to us. Sometimes this requires vendor-provided powershell commandlets, or shell scripts, or using SSH to execute a script on a remote server, and sometimes using vendor-specific .NET libraries. We even have one product where we can only interact with it by directly reading and updating a SQL database.

I don't think there's a "best" language to use. We find that writing our code directly in javascript in vCO whenever possible helps keep all of our code organized, but in the end, you just use whatever language you're most comfortable with as long as the vendor has provided a way for that language to interface with the application.

[rszymczak]

Keep in mind that vCO is using rhino for Java<->JavaScript conversion and within vCO you only have a limited set of the types Rhino could provide, which limits you somewhat in what you can do.

Before tackleing from one approch to another you should really double check what APIs your producs offer (*sigh* if they don't - in my humble opinion - you should burn that trash). The choise of the approch compleatly depends on the answer to this question.

E.g. as bencouture already said: if your backend offers a REST API you - depending on what you want to do - are probably served well with the REST plugin.

[TheVMinator]

OK great - as I'm picking and evaluation products for ones that do have good apis vs trash, what should I be looking for and in what order?  (For example, in an IPAM, CMDB, DNS, Ticket system)

1. REST is best?

2. SOAP is #2?

3. Third best option?

4.  Any API offerings that I should definitely stay clear of?

Please reorder my list to what you think...Your experience on working with APIs helpful...thanks!

[rszymczak]

Well. Define "best".

REST is popular and thus there are many resources available for it. It's popular for it's ease of use - so thats another good point. It's lightweight most of the time (atleast if useing JSON) which is good for mobile applications. It's using the very basic and simple structure of the internet (HTTP) and dosn't try to re-invent the wheel. Is it the best? Dunno. A good read though is How I Explained REST to My Wife | Looah. The original post was deleted due to some stupid gender bs.

Personally I don't like SOAP, but that's just my opinion. Third best? No idea. There are some (XML-RPC) that are still widely used but most of them are beeing replaced step by step by stuff like REST.

I guess in the end - since your goal seems to be vCO integration - the question will be:

- how difficult is it to integrate the API the product offers into vCO / is there a plugin for makeing calls to that API avaiable in vCO?

- what functions does the APIs expose and is it enough for what you want to do. In fact many companies claim to have a REST api by just implementing a bunch of GET methods. Don't get hooked, look closely, choose wisely depending on what your final goal is and how it may evolve in future.

[bencouture · Accepted solution]

I wouldn't say REST is necessarily "best", it's just what we prefer to use when possible. The plugin makes it pretty easy to use, and it's generally FAST. When we moved from running external scripts to using REST, we literally went from 3-5 minutes per call to under 5 seconds in some instances.

Our usual order goes:

1. REST (vCO plugin)

2. SOAP (also vCO plugin, but slightly more difficult to use than the REST plugin)

3. Powershell / shell scripts

One API that's given us particular trouble through vCO is XML-RPC. While this is a web API, we weren't ever able to get that to work without running shell scripts, which kind of defeats the purpose.

One more important factor: sometimes, one API will not expose all the same functionality as another API. We've had instances where the REST API didn't expose as much as the SOAP API, even though both were offered from the same product. Make sure whichever API you choose offers all the functionality you require, or you'll find yourself rewriting your integrations later.

[TheVMinator]

great input thanks all