Apache NiFi: Avoid these common pitfalls

Apache NiFi is an easy to use, powerful, and reliable system to process and distribute data. It has a powerful UI which can be used for both development and operations. In addition, the NiFi Registry is available to make promoting software from one environment to the next, easier. In order to use NiFi efficiently, I'd like to point out some common pitfalls when using NiFi.

Sonatype Nexus 2.x: Using the REST API to clean-up your repository

Sonatype provides Nexus. An extensive artifact Repository Manager. It can hold large amounts of stored artifacts and still requests get processed quickly. Also it has an extensive easy to use API which is a definite asset. When a project has been running for a longer period (say years), the repository often gets filled with large numbers of artifacts. This can become especially troublesome if artifacts are quite large in size such as for example JSF EAR files. These artifacts might not even have been released (be part of a deployed release). Nexus provides the option to remove artifacts older than a specific date. This however might also remove artifacts which are dependencies of other artifacts (older releases) which you might want to keep. When those other artifacts are build, the build might break because the artifacts it refers to, have been removed. In order to allow more fine grained control over what to remove, I've created the following script. The script uses only the releases repository (snapshots are not taken into account. not sure what the script does there) Disclaimer: first test if this script does what you want in your situation. It is provided as is without any warranties.

Sonatype Nexus 3.0. Using the new Groovy API

Sonatype Nexus 3.0 does not have the REST API which was available in Nexus 2.x (see the discussion here). This provides a challenge in case you want to automate certain tasks. Nexus 3 does provide a Groovy API however which allows you to write your own scripts and upload them to Nexus. You can then call your scripts and use the JSON result. In order to get this working however, several things need to be done. First the script needs to be developed (during which code completion comes in handy). Next the script needs to be condensed to a single line and put in a JSON request. After that, the JSON request needs to be send to a specific endpoint. You can imagine this can be cumbersome. Sonatype has provided Groovy scripts to deploy their Groovy scripts. See here. I've created something similar using Python so you do not require a download of dependencies, a JVM and a Groovy installation to perform this task. This makes it more easy to do this from for example a build-server.

Unleash the power of Java API's on your WLST scripts!

Oracle SOA Suite and many other Oracle products have extensive Java API's to expose their functionality. WLST can often be used for relatively course grained actions.  WLST (the version supplied in Weblogic 12.1.3) uses Jython 2.2.1. Jython is the Python scripting language implemented on the Java Virtual Machine. Jython allows easy integration with Java. In this article I describe how you can unleash the power of these Java API's on your WLST scripts!

Combine version control (SVN) and issue management (JIRA) to improve traceability

Version control and bug tracking systems are found in almost every software development project. Both contain information on release content. In version control, it is usual (and a best practice) to supply an issue number when code is checked in. Also it allows identification of code which is in a release (by looking at release branches). Issue management allows providing metadata to issues such as the fix release and test status. This is usually what release management thinks is in a release.

In this article I will provide a simple example on how you can quickly add value to your software project by improving traceability. This is done by combining the information from version control (SVN) and issue management (JIRA) to generate release notes and enforcing some version control rules.

To allow this to work, certain rules need to be adhered to.

• code is committed using a commit message or tag which allows linking of code to issue or change
• it should be possible to identify the code which is part of a release from version control
• the bug tracking system should allow a selection of issues per release

Oracle introduces API Manager!

Oracle has introduced a new product; API Manager (you can find the official documentation here). API Manager is an important addition to the already impressive Oracle SOA stack. In this article I'll explain what this new product does and how it helps in managing your API's. I will focus on the features and benefits you can have of this product and will also elaborate a little about my current experiences with it.