When someone mentions APIs what do you think of? Let’s look at the acronym and the discuss how I will be using it over the course or this blog series.
API stands for “Application Programming Interface”. This term is pretty broad as it is a connection between computers, programs and software services. APIs can be pubic or private, supported or unsupported. I will only be talking about Public / supported APIs within the scope of our ELM capabilities.
Accessing a specific API can be done via a SDK (software development kit) or via Rest APIs (Representational state transfer ). I will begin with focusing on Rest API.
Jim Ruehlin & Rosa Naranjo have created a landing page that consolidates all the existing API documentation available across jazz.net (link). This page provides grouping of existing APIs (both Rest and SDK based APIs), along with how to guides. One thing to notes is this page references “CLM”. CLM stands for Collaborative Lifecycle Management ( this is a legacy name for our IBM Engineering Lifecycle Management applications).
As a developer, we all have an innate definition of what an API is. An API is how we access some function of an application. APIs are exposed in SDKs (Software Development Kits), compiler or language libraries, and services. I am going to focus this set of blog posts on service based APIs. ELM utilizes a standards based Service Oriented Architecture called OSLC. OSLC or Open Services for Lifecycle Collaboration is specifically designed to address the software development process, utilizing a SOA approach. As such, the API end points and payload requirements are discoverable via services. I’ll be going thru this discovery process over a few blog posts.
However, let’s start with a quick review of our existing API Landing page and the menu on the right hand side. As you can see we have sections for basic concept, each of the applications and developing java applications.
General OSLC and CLM API information – The foundation for many of our APIs in ELM is OSLC. OSLC is an open standard for defining messages and APIs across various lifecycle processes. Getting a good understanding of OSLC is key for many of the topics we will discuss going forward.
Jazz Foundation – Many of the ELM applications are built on top of our Jazz platform. This foundational component supports a set of common APIs that should be the same regardless of the application you are working with.
Global Configuration Management – One of the most powerful features of IBM ELM is Global Configuration Management or GCM. GCM allows you to assemble configurations from across ELM applications. These Global Configs (GCs) can be reused in different versions or variants of software and product lines. GCM supports the OSLC APIs, a set of Rest API and a Client Extension SDK.
DOORS Next – Requirements management (AKA – DNG) allows for capturing, tracing, analyzing, and managing changes to requirements. There are many different API models that are supported by DNG include OSLC, both client and server SDKs, and Rest APIs for Modules, Reports, ReqIf, and other features.
Rational Team Concert (EWM) – Workflow management allows teams to create and manage work plans across multiple development projects utilizing Agile, SAFe (Scaled Agile Framework for Enterprises), or custom processes. The API’s supported by EWM have a lot of coverage in blogs and other resources, including the work of Ralph Schoon. Ralph has been blogging about EWM APIs for over a decade. Check out his blog at – https://rsjazz.wordpress.com/. EWM has support for OSLC, REST and SDK based APIs.
Rhapsody Model Manager – Architecture Management allows you to manager your models and code on the same configuration management server. It also provides linkage between requirements and work items across ELM. It provides a set of REST APIs for accessing artifacts for reporting.
Rational Quality Manager (ETM) – Engineering Test Management enables test planning and management supporting test execution, results reporting, and integration with other testing execution applications. Supporting both OSLC and REST based APIs, you may also create custom test automation adapters via APIs to integrate with third party test execution tools.
Reporting – ELM reporting is supported both by individual applications and across applications via the ELM Report Builder. This section provides details on LQE (the Lifecycle Query Engine) and Report Builder, along with Reporting APIs for Requirements (DNG), Test (ETM), and Workflow(EWM).
Plain Java Client or Jazz APIs – The above sections will have links to the appropriate plain java client and other Jazz APIs. This section provides a single place to get to them regardless of application supported.
If you’ve made it this far, you realize there really is a lot of API documentation and content for you to go thru. But how can you digest it all? In the next post I’ll take you thru the common entry point for understanding the APIs supported by a specific ELM application – the RootServices document!