Sample Service Introduction

You can learn what a RESTful web service is and how to build one with Spring alone, and Spring (which Java-based) isn’t the only choice when building web services. For example, Node.js runs on z/OS which allows JavaScript / TypeScript frameworks to used to build your APIs if you prefer those technologies.

Externally, regardless of the framework you choose, you use the same pattern to get going. You take a starter project (like the sample), then:

Clone it to your workstation: git clone https://github.com/zowe/sample-spring-boot-api-service Build & run it: gradlew bootRun

Once the build completes, the service starts:

Console messages from build and run gradle task

Once started, you can try the api/v1/greeting API from your browser to get some “Hello, world!” JSON:

After bypassing security errors and signing in with user and password “zowe” you can see the greeting API response

Deployment Overview

To deploy this service on z/OS, there are a few steps to complete:

Create and mount z/OS File System (zFS) Deploy artifacts (binaries) to z/OS Construct JCL and run the service as a batch job

Create and Mount a zFS

First, you need a space (a zFS) to deploy the API artifacts. Login to z/OS Unix Shell (you may need privileged authority to issue the command examples below, e.g. superuser ).

Allocate a z/OS File System (zFS) using zfsadm :

zfsadm define -aggregate IBMUSER.SAMPLAPI.ZFS -cylinders 100 -volumes WRKD23

Example response:

IOEZ00248I VSAM linear dataset IBMUSER.SAMPLAPI.ZFS successfully created.

Format the zFS:

zfsadm format -aggregate IBMUSER.SAMPLAPI.ZFS

Example response:

IOEZ00077I HFS-compatibility aggregate IBMUSER.SAMPLAPI.ZFS has been successfully created

Create a directory to hold the sample API artifacts:

mkdir /u/ibmuser/samplapi

Mount the zFS:

/usr/sbin/mount -v -f IBMUSER.SAMPLAPI.ZFS /u/ibmuser/samplapi

Example response:

FOMF0502I Mount complete for IBMUSER.SAMPLAPI.ZFS

Deploy Artifacts

Next, you’ll need to upload several binary artifacts from your workstation to the newly allocated zFS. You can upload artifacts via ftp , sftp , scp or Zowe CLI . zowe commands will be used in the remaining examples.

Deploy the Sample Service API JAR

To obtain the sample service JAR (which contains the runnable API service code), run gradlew build from your workstation sample service project.

The default artifact will be placed in build/libs/zowe-apiservice-0.0.1-SNAPSHOT.jar .

In the z/OS Unix Shell, create a directory for the zowe-apiservice-0.0.1-SNAPSHOT.jar : mkdir /u/ibmuser/samplapi/jars

Upload the zowe-apiservice-0.0.1-SNAPSHOT.jar as a binary artifact:

zowe files upload ftu build/libs/zowe-apiservice-0.0.1-SNAPSHOT.jar "/u/ibmuser/samplapi/jars/zowe-apiservice-0.0.1-SNAPSHOT.jar" --binary

Deploy the Sample Service Configuration YAML

Next, create a directory for the application.yml . This will contain configuration overrides for when the service is started on z/OS using a Spring run-time parameter: --spring.config.additional-location .

In the z/OS Unix shell, create a config directory: mkdir /u/ibmuser/samplapi/config

Then, upload the config/local/application.yml as a binary artifact:

zowe files upload ftu "config/local/application.yml" "/u/ibmuser/samplapi/config/application.yml" --binary

If this file YAML is edited on z/OS, it must remain in ASCII format (not EBCDIC).

Lastly, add the “ zos ” profile to the first line, change the address , port , and the paths to the keystore and truststore locations:

Change the address and port for access from off-platform

For the address you can ping the host name of LPAR from your workstation.

Deploy keystore and truststore

Rather than describe the purposes of keystore and truststore in this article, you can read about them here. For now, we’ll blindly upload the artifacts knowing that they’re needed 😃:

Upload keystore:

zowe files upload ftu "config/local/keystore.p12" "/u/ibmuser/samplapi/config/keystore.p12" --binary

Upload truststore:

zowe files upload ftu "config/local/truststore.p12" "/u/ibmuser/samplapi/config/truststore.p12" --binary

Construct JCL & Run

With all artifacts uploaded, you can run the sample server from the z/OS Unix Shell using java commands or via a started task / batch job with JCL.

Start via Java Commands

To start the server using a java command, you can issue:

java -Xquickstart -jar /u/ibmuser/samplapi/jars/zowe-apiservice-0.0.1-SNAPSHOT.jar --spring.config.additional-location=file:/u/ibmuser/samplapi/config/application.yml

Here is a snippet of the messages seen after startup on z/OS:

java command using git bash terminal and ssh to z/OS Unix

From here, you can stop the server via: Ctrl+C

Start via z/OS Batch Job

Customize the JCL below to run the server as a batch job:



This will need customized for your installations location of java and where you put the sample API service

Submit the JCL and view output in the SYSPRINT DD:

You can stop the server via: STOP SAMPLAPI .

Running Example

When the server is started (either through a java command or JCL), you can test the sample api/v1/greeting API through your web browser (as described above) — you only need to substitute the proper hostname / IP in place of localhost .

You need to use your real mainframe credentials here instead of “zowe” because the zos profile activates SAF-backed security. That is, SAF is used to authenticate to the API with basic authentication.

Summary

This covered the steps of cloning a sample API service and deploying the service to z/OS. A terse description of the steps can also be found here. In the future, I hope to describe how to make this service discoverable in the Zowe API ML, some aspects of security, and how to invoke native (z/OS linkage) services in an API request.