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.
Related
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.
Is it possible to have multiple versions of service(s) deployed in production at the same time. From my assumption, this should be pretty common pattern for microservice/api based projects or mobile projects. I want to know how do you do it and what are common pattern in industry for this kind of problems. It would be helpful if your answers around AWS environment or Kubernetes environment.
Thanks in Advance.
Is it possible to have multiple versions of service(s) deployed in production at the same time
Yes, it is possible. The idea is to keep all used microservices in production (v1, v2 ...) at the same time and to bring down the versions that are not used anymore. For this, you should somehow know when a version is not used anymore.
AFAIK, you have to options:
For every new version you make a new endpoint (like /v2/someApiCall) that is connected to the same (now upgraded) microservice and gradually instruct clients to use the new endpoind; when the old endpoint is not used anymore you deleted it; this is the preferred way.
For every new version you make a new microservice that share the same persistence with the old microservice; you should avoid the use of this solution; Netflix uses this strategy in rare occasions when the cost of changing old consumers is too high.
You can read more at page 62 from Building microservices by Sam Newman.
With AWS API Gateway you could deploy multiple versions of your code and switch between them from the mapping templates, as explained here. You might also want to look into stage variables.
Assuming your are exposing services over An HTTP REST API, the general standard is to always base line your service urls with a version.
Eg,
/v1/account/getUserInfo
If you need to release a new version, expose it over:
/v2/account/getUserInfo
Where v2 can run over a different branch of the codebase.
I have blogged about this: Multi-version Service Discovery using Spring Cloud Netflix Eureka and Ribbon, focussed on Spring Cloud Netflix components / libraries though.
But the idea is to deploy a new version of the artifact / binary in a new host / VPS / Container and have the service register with a registry server (Eureka, Consul, ....) and include metadata about the API versions it supports (v1, v2, ...). Client apps would discover which host / container / ... serves the API version needed.
How to call TWS beans from another Java EE server like JBoss or even WAS Liberty Profile?
I've no direct experience with JBoss or Liberty, but we have tried several times from Tomcat without success. Maybe it's possible with Liberty but as said I've never tried it.
This is one of the reason we are moving to REST APIs that makes interoperability much easier. REST APIs has been introduced on TWSd with 9.3 FP2, but are still not available on TWSz.
If you need them on TWSz, you can try to open an RFE to push this new feature.
If you don't have a product/release that natively support REST APIs, a possible pattern is to implement your own REST APIs based on J2EE APIs and deploy them as an additional WAR on the engine/connector WAS, and the call these REST APIs from your JBoss, Liberty.
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
I'm building a mobile application using IBM Worklight. In an adapter, I need to use some functionality which is provided by a third party JavaScript file. I want to know if it's possible to include such a file on the server? If not, what is the alternative?
At the moment there is no way to include an external JavaScript library in the Adapter code. Currently the only workaround is to copy the library code to the adapter.
In Worklight 6.0.0, IBM introduced Node.js adapters, touting "a huge selection of third-party modules extending connectivity and providing implementations of various common backend constructs". That sounds like JS library support to me. Details here:
https://www.ibm.com/developerworks/community/blogs/worklight/entry/a_preview_of_node_js_adapters_in_worklight_6_0_0?lang=en