Integration between HP ALM and Appium - selenium

Is it possible to establish a connection between HP ALM and Appium to automate the test execution in ALM?

Yes, it is possible. You will have to use a different API for ALM. You've got 2 ways to achieve this:
Using HP-ALM OTA API (OTA API Reference: Click here)
Pros:
a.) OTA API is a huge C# API with enormous variety of functionalities which can be used.
b.) Object Based API. Most programmers can work easily use it.
Cons:
a.) Platform dependent. Need to register the OTA COM Client .dll in your local system (Windows) to use it.
b.) HP might migrate entirely to REST API in future and stop support/updates for COM API.
Using HP-ALM REST API (REST API Reference: Click here)
Pros:
a.) Platform independent. Does not require any client-side software to be installed/registered. Post HTML requests to a server and process the XML-formatted results.
b.) API of the future. HP might migrate entirely to REST API in future.
Cons:
a.) It primarily focuses only on simple CRUD operations of core entities in the client (CRUD = create, read, update, delete).
b.) Not all ALM functionalities exposed through this API.
You can also have a look at my git repo: myGitRepo. Have got 2 projects implemented using OTA COM API. Both have got a UI with functionalities to achieve several day to day manual tasks performed in ALM. There are several enhancements I am currently working on.

Have a look at Agiletestware Bumblebee. It provides integration with Appium and Selenium on a source code level with a set of Java annotations.
See the detailed guide here.
Disclaimer: I'm developer of Bumblebee

Related

API Automation through Java or Postman

In my company we use Ruby to create a framework for API automation and I have heard we can automate using Postman or SoapUI. So why do we have to create a automation framework when we already have tools for it?
It is like a buying a suit at the clothes shop versus going to a tailor to get a suit that is measured especially to your needs.
Using an existing tool will require less initial setup, you will have access to a lot of commonly needed features, without reinventing the wheel. For instance, in Postman there are available test snippets that you can use with little or no programming knowledge. Tools such as ReadyAPI, Katalon Studio, Robot Framework, SoapUI, etc. usually don't have a too steep of a learning curve, compared to developing a customer automation framework from scratch.
Using tools is fine, especially if you understand how they work in the background and have analysed the testing needs for your particular project. For example, a tool like REST Assured makes writing tests for RESTful webservices very easy, but it's actually very complex in the background.
You would build an inhouse automation framework if after researching the existing solutions, you realize they don't fully provide all that you need. A well designed/architectured framework will be far more customizable than any other tool, although it will require more initial work and maintenance as well.
In terms of using a custom test automation framework your testers will generally have to be more technical, more like SDETs rather than typical testers, but does not always has to be the case - I have seen automation frameworks build by developers and the testers would only write tests inside it by re-using the methods in the framework.
Lastly I would advise you to do some experimentation, try one of the commercial or Open Sources tools for API testing and after doing some testing with it try doing the same with a more hands-on approach, like using Python's Request client Apache Http client for Java, but every language has it's equivalent.

Anypoint CLI VS ARM REST Services (which one is preferred for Automated Deployment?) Using Cloud Console on-premis Deployment

I wanted to Automate the Cloud Console on-premis Deployment process. I see two options to deploy the services using anypoint-cli or Rest API. Can some one please let me know what are the differences between them and which one should i choose(In terms of long term support) ?
Anypoint cli is a command line tool to interact with the REST API. It might not provide access to every endpoint of the API.
Using the API directly requires that you make the API requests in some programming or scripting language.
You should choose the one that makes more sense to you, and your use case. That can not be determined here.

Automated Testing of Nifi flows using Jenkins

Is there any way to automatically run regression/functional tests on Nifi flows using Jenkins pipeline ?
Searched for it, without any success.
Thanks for your help.
With the recent release of NiFI-1.5.0 and NiFi-Registry-0.1.0, the community has come together to produce a number of SDLC/CICD integration tools to make using things like Jenkins Pipeline easier.
There is both Python (NiPyAPI), and Java (NiFi-Toolkit-CLI) API wrappers being produced by a team of collaborators to allow scripted manipulation of NiFi Flows across different environments.
Common functions include interaction with integrated version control, import/export of flows as JSON documents, deployment between environments, start/stop of flows, etc.
So, we are working quickly towards supporting things like an integrated wrapper for declarative Jenkins Pipelines, and I would add it is being done fully in public codebase under the Apache license, so we (I am the lead NiPy author) would welcome your collaboration.

Programmable Control of Niagara

How to make an external program control Tridium Niagara framework? I see two options; Which one is correct:
1) Niagara allows addition of 3rd party code to provide an API, and someone else has already done that and we can use it.
2) Niagara allows 3rd party code to do API but we have to write our own.
Niagara installations can be configured to process many different network control protocols driven by an external process across the network, for example by BACnet. The Niagara instance can be configured internally in many different ways to respond to control from across the network.
Niagara 4.x prominently features Web GUIs, including Javascript client widgets and server Javascript, or the server can respond to the Web GUI activity with its other configuration and scripting methods.
For any real complexity beyond the bundled network drivers or HTTP, 3rd party modules coded in Java are used. These would typically be coded as Niagara drivers, processing data over serial or sockets.
Niagara's APIs are mostly open. But Niagara is a complex environment. Completing Tridium's week-long developer training/certification is typically required to produce a proper module.
There are some external API's that Tridium built into AX. oBIX and Bajascript.
I've written external oBIX programs in both Java and Python to pull data from a remote Jace. You'll have to add the oBIX service and export the points you want to see.
Bajascript is a javascript library Tridium uses to interact with the system as well. I believe they released Bajascript 2.0 not to long ago. http://www.bajascript.com
If those don't do what you like, you'll more than likely need to write your own API to handle it.

Connecting to JIRA using Plain JAVA APIs

This is my first question ever in Stack-Overflow!
I am beginner in JIRA. So I wanted to know if there is any stable platform to connect from Java to JIRA without using REST API?
Can I use native Java libraries or any other additional libraries to connect to JIRA?
Yup, atlassian created jira-rest-java-client but doesn't "formally" support it...but is open source...last update was 2014-10-09...so seems maintained.
There is also the SOAP services, which are deprecated but still supported in JIRA 6. They provide instructions on how to build a SOAP client. They'll be phased out, replaced by the REST endpoints, moving forward.