Optim Service Interface usage guide

A guide for developing a custom Optim user experience using the Optim Service Interface

This article demonstrates how to create a custom user experience for managing Optim® services by tapping into functionality provided by the Optim Service Interface (OSI). The OSI provides a headless public interface to a number of the same back-end web services used by the Optim Manager web application. It allows you to create your own front end that communicates with public RESTful resources through the marshaling of clearly defined XML payloads. A sample web application demonstrating this power and flexibility accompanies this article.

Share:

Al Finkelstein (alfinkel@us.ibm.com), Optim Infrastructure Architect, IBM

Al FinkelsteinAl Finkelstein works in the InfoSphere Optim group as the infrastructure team architect. Since joining IBM in 2007, he has worked on various Optim initiatives such as the Optim Service Interface, the Optim Connection Manager, and Services on Demand. Prior to his time at IBM, Al spent 15 years fine-tuning his development, database administration, and consulting skills at various Fortune 500 institutions and government agencies. He holds a degree in Computer Science from Rutgers College in New Brunswick, New Jersey.



21 November 2013

Also available in Chinese

Introduction

The OSI is a collection of public RESTful web service APIs that communicates with Optim SOA back-end web services. These public RESTful APIs provide you with the ability to marshal user friendly and consumable XML payloads to and from private Optim back-end web services. Through these RESTful APIs, the Optim Service Interface offers access to much of the same functionality that you would normally encounter while using the Optim Manager but without the constraints of the Optim Manager user interface.

If you are looking to take advantage of Optim Manager capabilities without the Optim Manager user interface restrictions, you can utilize the OSI and develop your own custom user experience by creating RESTful web client applications that interact with the set of OSI-provided public RESTful APIs. The OSI imposes no restrictions on the language used to develop these client applications that communicate with the OSI RESTful web services (Java, C, Ruby, Python, Groovy, .Net, can all be used). The web services exposed by the OSI are all contract based and discoverable via XML Schema Definition (XSD) and Web Application Description Language (WADL).

Audience

This article is intended for Optim customers interested in creating a custom user experience based on features and functionality provided by the OSI.

Prerequisite knowledge

This article strives to use standard language and diagrams where at all possible, so a general knowledge of software architectural terminology is beneficial. Also a general knowledge about the Optim suite of products, especially the Optim Service Interface, is required. This article assumes that you possess a basic knowledge of JEE, common Web technologies, Java (or similar programming language), XML, and HTML.

Terminology

Table 1. Glossary of Terms
Term/ConceptDefinition/Description
OSIOptim Service Interface
RESTRepresentational state transfer is a style of software architecture. A RESTful web service and a RESTful API are essentially the same. Both terms are used interchangeably throughout this article.
SOAService Oriented Architecture
GUIGraphical User Interface
XMLExtensible Markup Language
WADLWeb Application Description Language
XSDXML Schema Definition
DOMDocument Object Model

Purpose

The goal of this article is to provide you with a repeatable process that demonstrates successful interaction with the public web services provided by the Optim Service Interface. It is this repeatable process that you can use to develop your own user experience that communicates with the OSI.

A sample web client servlet written in Java is supplied with this article and the code, which can be found in the Download section of this article, is referenced throughout in an attempt to further illustrate the interaction between a custom user front end and the OSI. Although the sample web client servlet code is written in Java, you can apply the overall repeatable process that it illustrates to any web client application written in any programming language (that is, Java, C, Ruby, Python, Groovy, .Net, and so on).

Finally, while the outward appearance of the application generated as a result of the provided sample code may be somewhat unremarkable, the code itself does a good job at illustrating the repeatable, simple process that demonstrates communication with the OSI and that can be replicated in a variety of different languages.


RESTful web services

In order to fully understand the OSI and how to develop web client applications that communicate with the OSI, it is important to, at the very least, have a general understanding of what RESTful web services are. The following is a brief description of RESTful web services.

RESTful web services are implemented using HTTP and the principles of Representational State Transfer. A RESTful web service or RESTful API is a collection of resources with the following defining characteristics:

  • A RESTful web service must have a base URI.
  • A RESTful web service must use an Internet media type such as XML or JSON for request and response payloads that it supports.
  • A RESTful web service must provide a set of operations using HTTP request methods.
  • A RESTful web service must be hypertext driven.
  • A RESTful web service must be stateless. This means that the state of the client web application is irrelevant to the RESTful web service. The RESTful web service is only interested in processing requests and returning responses (headers and payload) based on the request method and request payload content.

For greater detail on RESTful web services, check the Resources section of this article.


The OSI RESTful API

The OSI is a collection of public RESTful web services that expose functionality normally provided by the Optim Manager without the constraints enforced by the Optim Manager user interface. This essentially makes the OSI a headless or faceless version of the Optim Manager. To establish a custom user experience using the OSI, you must develop a web client application that interfaces with the OSI, thereby tapping into the back-end functionality normally provided by the Optim Manager.

The OSI RESTful API roadmaps

Each OSI web service has a resource.xsd and a resource.wadl that can be retrieved by interrogating each web service with an HTTP GET request to the web service base URI followed by either a /?xsd or a /?wadl. These two documents provide you and ultimately the web client application with a roadmap of how to construct a desired HTTP request payload and how to send that payload via the desired HTTP request method to the OSI. These two documents also provide you and ultimately the web client application with a roadmap of how to process the returned HTTP response and how to deconstruct the response payload returned from the OSI. For convenience, each API's .xsd and .wadl files can also be found in the Download section of this article.

The resource.xsd

A resource.xsd file contains the request and response payload templates for a given RESTful API. You would use a resource.xsd as a reference when constructing request payloads for certain functionality provided by the RESTful API and also when deconstructing response payloads returned by the RESTful API.

The resource.wadl

A resource.wadl file contains details on how to construct a URL based on the base URI for a given RESTful API. It also provides information regarding whether a request payload is necessary and what form that payload should take. It does this by referencing the resource.xsd and pointing to which resource.xsd top level element template should be used for a payload. The resource.wadl does the same for any response payloads as well. Finally, the resource.wadl provides a list of possible response codes and their meaning. You would use the information provided by a resource.wadl as a reference when constructing HTTP request URLs, request payloads, and when processing HTTP responses and deconstructing any potential response payloads.

The Optim Connection Request API

The Optim Connection Request API is the OSI public RESTful API that provides the ability to query the Optim directory connection information. With this method, the OSI allows a web client application to issue an HTTP GET method to retrieve a list of all available Optim directory connections known by the Optim connection manager.

  • Retrieve a list of all Optim directory connections:
    • Request method: GET
    • API URL: /connection
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:connections xmlns:ns2="http://www.ibm.com/optim/xsd/connection/9.1.0">
          <ns2:connection>
              <id>e1a93332-701b-48d7-bdc6-c20adb09ba51</id>
              <name>OPTIMDIR1</name>
              <description>Optim directory on local Oracle XE</description>
              <status>Complete</status>
              <vendor>Oracle</vendor>
              <version>11.2</version>
              <jdbcUrl>jdbc:oracle:thin:@localhost:1521:xe</jdbcUrl>
          </ns2:connection>
      </ns2:connections>

The Optim Service Request API

The Optim Service Request API is the OSI public RESTful API that provides the ability to query Optim service request information. With this method, the OSI allows a web client application to issue HTTP GET methods to retrieve a list of all available Optim services as well as details for any given Optim service.

  • Retrieve a list of all Optim services:
    • Request method: GET
    • API URL: /service/{connection-name}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:services xmlns="http://www.w3.org/2005/Atom" 
                 xmlns:ns2="http://www.ibm.com/optim/xsd/srm/9.1.0">
          <link href="http://localhost:8080/server/service/
                             234d7245-aa47-44cb-b647-650734d200fd"/>
          <link href="http://localhost:8080/server/service/
                             79550682-e362-464d-9a0b-eae9a046083f"/>
          <link href="http://localhost:8080/server/service/
                             7c354125-4f2a-4d94-bfab-0711d2270af8"/>
          <link href="http://localhost:8080/server/service/
                             52abadce-abd3-434e-8c51-3a76c7a3d2f0"/>
          <link href="http://localhost:8080/server/service/
                             c73f9a81-d7d6-4998-adb4-37bc27071128"/>
      </ns2:services>
  • Retrieve service details:
    • Request method: GET
    • API URL: /service/{connection-name}/{service-id}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:service xmlns:ns2="http://www.ibm.com/optim/xsd/srm/9.1.0">
          <serviceId>234d7245-aa47-44cb-b647-650734d200fd</serviceId>
          <serviceName>OSIDEMO.ERCUST10K</serviceName>
          <servicePath>OPTIMDIR/OSIDEMO</servicePath>
          <serviceType>com.ibm.nex.model.oim.distributed.ExtractRequest</serviceType>
          <servicePlatform>com.ibm.nex.ois.runtime.productplatform.distributed
          </servicePlatform>
      </ns2:service>

The Optim Server API

The Optim Server API is the OSI public RESTful API that provides the ability to query Optim server information. With this method, the OSI allows a web client application to issue an HTTP GET method to retrieve a list of all available Optim servers.

  • Retrieve a list of all Optim servers:
    • Request method: GET
    • API URL: /runtime
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:servers xmlns:ns2="http://www.ibm.com/optim/xsd/rr/9.1.0">
          <rsiURL>http://localhost:12000/</rsiURL>
      </ns2:servers>

The Optim Service Execution API

The Optim Service Execution API is the OSI public RESTful API that provides the ability to execute an Optim service. With this method, the OSI allows a web client application to issue an HTTP POST method along with an XML payload detailing the service to be executed. In return, the OSI runs the specified service and also returns an appropriate response and payload to the web client application.

  • Execute a service:
    • Request method: POST
    • API URL: /execute/{connection-name}/{service-id}
    • Request payload example:
      <?xml version="1.0" encoding="UTF-8"?>
      <sem:serviceRequestExecutionInput 
          xmlns:sem="http://www.ibm.com/optim/xsd/sem/9.1.0" 
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
          xsi:schemaLocation="http://www.ibm.com/optim/xsd/sem/9.1.0 resource.xsd ">
          <serviceId>234d7245-aa47-44cb-b647-650734d200fd</serviceId>
          <serviceName>OSIDEMO.ERCUST10K</serviceName>
          <servicePath>OPTIMDIR/OSIDEMO</servicePath>
          <rsiURL>http://localhost:12000/</rsiURL>
      </sem:serviceRequestExecutionInput>
    • Response Codes:
      • 202: Accepted
      • 400: Bad request made
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:executionResults xmlns:ns2="http://www.ibm.com/optim/xsd/sem/9.1.0">
          <executionId>66dbf3ac-5768-4df4-9dfb-17ead3033b93</executionId>
          <serviceId>234d7245-aa47-44cb-b647-650734d200fd</serviceId>
          <serviceName>OSIDEMO.ERCUST10K</serviceName>
          <servicePath>OPTIMDIR/OSIDEMO</servicePath>
      </ns2:executionResults>

The Optim Service Monitoring API

The Optim Service Monitoring API is the OSI public RESTful API that provides the ability to query and purge Optim service execution instance data. With this method, the OSI allows a web client application to issue HTTP GET methods to retrieve a list of all available Optim service execution instances, retrieve details for any given Optim service execution instance, retrieve a list of artifacts for any given Optim service execution instance, and retrieve the actual content for any service execution instance artifact. The OSI also provides a web client application with the ability to issue an HTTP DELETE method that will purge any given service execution instance.

  • Retrieve a list of all service instances:
    • Request method: GET
    • API URL: /monitor/{connection-name}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:serviceInstances xmlns="http://www.w3.org/2005/Atom" 
                             xmlns:ns2="http://www.ibm.com/optim/xsd/sim/9.1.0">
          <link href="http://localhost:8080/server/monitor/
                             892ea9ab-af33-40a1-acbb-110dc6cd74f3"/>
          <link href="http://localhost:8080/server/monitor/
                             0f5f5bf3-5f29-4d53-8575-2ff2cbab1c08"/>
          <link href="http://localhost:8080/server/monitor/
                             8630618c-3c08-4b76-b3cf-4dd6fb06fad3"/>
          <link href="http://localhost:8080/server/monitor/
                             66dbf3ac-5768-4df4-9dfb-17ead3033b93"/>
      </ns2:serviceInstances>
  • Retrieve service instance details:
    • Request method: GET
    • API URL: /monitor/{connection-name}/{execution-id}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:serviceInstance xmlns:ns2="http://www.ibm.com/optim/xsd/sim/9.1.0">
          <id>66dbf3ac-5768-4df4-9dfb-17ead3033b93</id>
          <serviceId>234d7245-aa47-44cb-b647-650734d200fd</serviceId>
          <startTime>1355504913223</startTime>
          <endTime>1355504990011</endTime>
          <returnCode>0</returnCode>
          <artifactList>
              <artifactName>run.log</artifactName>
              <artifactName>svc_request.xml</artifactName>
              <artifactName>execution.properties</artifactName>
              <artifactName>svc_response.xml</artifactName>
          </artifactList>
      </ns2:serviceInstance>
  • Retrieve a list of artifacts for a service instance:
    • Request method: GET
    • API URL: /monitor/{connection-name}/artifacts/{execution-id}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:serviceInstanceArtifacts xmlns="http://www.w3.org/2005/Atom" 
                               xmlns:ns2="http://www.ibm.com/optim/xsd/sim/9.1.0">
          <link href="http://localhost:8080/server/monitor/
                      66dbf3ac-5768-4df4-9dfb-17ead3033b93/run.log"/>
          <link href="http://localhost:8080/server/monitor/
                      66dbf3ac-5768-4df4-9dfb-17ead3033b93/svc_request.xml"/>
          <link href="http://localhost:8080/server/monitor/
                      66dbf3ac-5768-4df4-9dfb-17ead3033b93/execution.properties"/>
          <link href="http://localhost:8080/server/monitor/
                      66dbf3ac-5768-4df4-9dfb-17ead3033b93/svc_response.xml"/>
      </ns2:serviceInstanceArtifacts>
  • Retrieve a specific artifact:
    • Request method: GET
    • API URL: /monitor/{connection-name}/{execution-id}/{artifact-name}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload will be the artifact requested
  • Remove a service instance:
    • Request method: DELETE
    • API URL: /monitor/{connection-name}/{execution-id}
    • Response Codes:
      • 204: No content
      • 400: Bad request made
      • 404: Not found

The Optim Work Order Management API

The Optim Work Order Management API is the OSI public RESTful API that provides the ability to interact with Optim Services on Demand work order data. With this method, the OSI allows a web client application to issue HTTP GET methods to retrieve lists of available work orders, active states, and reachable transitions, as well as details for any given work order. A web client application is also given the ability via the OSI to issue HTTP POST and PUT methods accompanied by request payloads in order to create work orders, update and transition those work orders, and ultimately execute those work orders. The OSI returns responses in each case based on the requested operation. Finally, a web client application can issue an HTTP DELETE method to purge any given work order using this API.

  • Retrieve all active states:
    • Request method: GET
    • API URL: /workorder/{connection-name}/states /{workflow-id}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:states xmlns:ns2="http://www.ibm.com/optim/xsd/workorder/9.1.0">
          <ns2:state>
              <stateId>100</stateId>
              <wfId>1</wfId>
              <stateName>NEW</stateName>
          </ns2:state>
          <ns2:state>
              <stateId>200</stateId>
              <wfId>1</wfId>
              <stateName>REQUESTED</stateName>
          </ns2:state>
          ...
          <ns2:state>
              <stateId>999</stateId>
              <wfId>1</wfId>
              <stateName>TERMINATED</stateName>
          </ns2:state>
      </ns2:states>
  • Retrieve reachable transitions:
    • Request method: GET
    • API URL: /workorder/{connection-name}/transitions /{workflow-id}/{state-id}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:transitions xmlns:ns2="http://www.ibm.com/optim/xsd/workorder/9.1.0">
          <ns2:transition>
              <id>2</id>
              <wfId>1</wfId>
              <oldStateId>200</oldStateId>
              <transitionName>DENY</transitionName>
              <newStateId>250</newStateId>
              <owner>2</owner>
          </ns2:transition>
          ...
          <ns2:transition>
              <id>5</id>
              <wfId>1</wfId>
              <oldStateId>200</oldStateId>
              <transitionName>APPROVE</transitionName>
              <newStateId>300</newStateId>
              <owner>2</owner>
          </ns2:transition>
      </ns2:transitions>
  • Create a work order:
    • Request method: POST
    • API URL: /workorder/{connection-name}/{transition-id}
    • Request payload example:
      <?xml version="1.0" encoding="UTF-8"?>
      <workorder:workorder 
           xmlns:atom="http://www.w3.org/2005/Atom" 
           xmlns:workorder="http://www.ibm.com/optim/xsd/workorder/9.1.0" 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xsi:schemaLocation="http://www.ibm.com/optim/xsd/workorder/9.1.0 
           resource.xsd ">
        <wfId>1</wfId>
        <stateId>100</stateId>
        <description>The work order description</description>
        <priority>Within 8 Hours</priority>
        <comments>The work order comments</comments>
        <createdBy>CREATORID</createdBy>
      </workorder:workorder>
    • Response Codes:
      • 201: Created
      • 400: Bad request made
  • Update a work order:
    • Request method: PUT
    • API URL: /workorder/{connection-name}/{work-order-id}
    • Request payload example:
      <?xml version="1.0" encoding="UTF-8"?>
      <workorder:workorder 
           xmlns:atom="http://www.w3.org/2005/Atom" 
           xmlns:workorder="http://www.ibm.com/optim/xsd/workorder/9.1.0" 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xsi:schemaLocation="http://www.ibm.com/optim/xsd/workorder/9.1.0 
           resource.xsd ">
        <wfId>1</wfId>
        <stateId>100</stateId>
        <description>The work order description</description>
        <priority>Within 8 Hours</priority>
        <comments>The work order comments - UPDATED</comments>
        <createdBy>CREATORID</createdBy>
      </workorder:workorder>
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
  • Transition and update a work order:
    • Request method: PUT
    • API URL: /workorder/{connection-name}/{work-order-id}/{transition-id}
    • Request payload example:
      <?xml version="1.0" encoding="UTF-8"?>
      <workorder:workorder 
           xmlns:atom="http://www.w3.org/2005/Atom" 
           xmlns:workorder="http://www.ibm.com/optim/xsd/workorder/9.1.0" 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xsi:schemaLocation="http://www.ibm.com/optim/xsd/workorder/9.1.0 
           resource.xsd ">
        <wfId>1</wfId>
        <stateId>100</stateId>
        <description>The work order description</description>
        <priority>Within 8 Hours</priority>
        <comments>The work order comments (TRANSITION AND UPDATE)</comments>
        <createdBy>CREATORID</createdBy>
      </workorder:workorder>
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
  • Remove a work order:
    • Request method: DELETE
    • API URL: /workorder/{connection-name}/{work-order-id}/{transition-id}
    • Response Codes:
      • 204: No content
      • 400: Bad request made
      • 404: Not found
  • Retrieve all work orders:
    • Request method: GET
    • API URL: /workorder/{connection-name}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:workorders xmlns="http://www.w3.org/2005/Atom" 
               xmlns:ns2="http://www.ibm.com/optim/xsd/workorder/9.1.0">
          <link href="http://localhost:8080/server/workorder/10008"/>
          <link href="http://localhost:8080/server/workorder/10011"/>
          <link href="http://localhost:8080/server/workorder/10015"/>
      </ns2:workorders>
  • Retrieve work order details:
    • Request method: GET
    • API URL: /workorder/{connection-name}/{work-order-id}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:workorder xmlns:ns2="http://www.ibm.com/optim/xsd/workorder/9.1.0">
          <id>10008</id>
          <wfId>1</wfId>
          <stateId>350</stateId>
          <description>Work order 10008 description</description>
          <priority>Within 48 hours</priority>
          <comments>Work order 10008 comments
      
                    admin , Fri Nov 09 08:53:55 CST 2012
          </comments>
          <createdBy>admin</createdBy>
          <createdDate>1351710653900</createdDate>
      </ns2:workorder>
  • Execute a work order:
    • Request method: POST
    • API URL: /workorder/{connection-name}/execute/{work-order-id}
    • Request payload example:
      <?xml version="1.0" encoding="UTF-8"?>
      <workorder:workOrderExecution 
           xmlns:atom="http://www.w3.org/2005/Atom" 
           xmlns:workorder="http://www.ibm.com/optim/xsd/workorder/9.1.0" 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xsi:schemaLocation="http://www.ibm.com/optim/xsd/workorder/9.1.0 
           resource.xsd ">
        <workOrderId>10015</workOrderId>
        <proxyURL>http://localhost:12000/</proxyURL>
        <executedBy>THEEXECUTOR</executedBy>
      </workorder:workOrderExecution>
    • Response Codes:
      • 202: Accepted
      • 400: Bad request made
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8"?>
      <workorder:executionResults xmlns:atom="http://www.w3.org/2005/Atom" 
           xmlns:workorder="http://www.ibm.com/optim/xsd/workorder/9.1.0" 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xsi:schemaLocation="http://www.ibm.com/optim/xsd/workorder/9.1.0 
           resource.xsd ">
        <executionId>66dbf3ac-5768-4df4-9dfb-17ead3033b93</executionId>
        <serviceId>234d7245-aa47-44cb-b647-650734d200fd</serviceId>
      </workorder:executionResults>

The Optim Scheduler API

The Optim Scheduler API is the OSI public RESTful API that provides the ability to manage Optim job schedules. With this method, the OSI allows a web client application to issue HTTP GET methods to retrieve a list of Optim job schedules as well as details for any given Optim job schedule. A web client application is also given the ability via the OSI to issue HTTP POST and PUT methods accompanied by request payloads in order to create Optim job schedules and update those Optim job schedules. The OSI returns responses in each case based on the requested operation. Finally a web client application can issue an HTTP DELETE method to purge any given Optim job schedule using this API.

  • Retrieve all scheduler entries:
    • Request method: GET
    • API URL: /scheduler/{connection-name}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:schedules xmlns="http://www.w3.org/2005/Atom" 
           xmlns:ns2="http://www.ibm.com/optim/xsd/scheduler/9.1.0">
          <link href="http://localhost:8080/server/scheduler/
                             fbf1cdd5-bdf7-4682-96ad-722672af0001"/>
          <link href="http://localhost:8080/server/scheduler/
                             fbf1cdd5-bdf7-4682-96ad-722672af0002"/>
      </ns2:schedules>
  • Retrieve scheduler entry details:
    • Request method: GET
    • API URL: /scheduler/{connection-name}/{schedule-id}
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
    • Response payload example:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <ns2:schedule xmlns:ns2="http://www.ibm.com/optim/xsd/scheduler/9.1.0">
          <id>fbf1cdd5-bdf7-4682-96ad-722672af0001</id>
          <serviceId>234d7245-aa47-44cb-b647-650734d200fd</serviceId>
          <startDate>1321033535125</startDate>
          <endDate>0</endDate>
          <repeatCount>0</repeatCount>
          <repeatInterval>10</repeatInterval>
          <schedulerTaskType>SOA_SERVICE</schedulerTaskType>
          <proxyURL>http://localhost:12000/</proxyURL>
      </ns2:schedule>
  • Create a scheduler entry:
    • Request method: POST
    • API URL: /scheduler/{connection-name}/{schedule-id}
    • Request payload example:
      <?xml version="1.0" encoding="UTF-8"?>
      <scheduler:schedule xmlns:atom="http://www.w3.org/2005/Atom" 
           xmlns:scheduler="http://www.ibm.com/optim/xsd/scheduler/9.1.0" 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xsi:schemaLocation="http://www.ibm.com/optim/xsd/scheduler/9.1.0 
           resource.xsd ">
        <id>fbf1cdd5-bdf7-4682-96ad-722672af0001</id>
          <serviceId>234d7245-aa47-44cb-b647-650734d200fd</serviceId>
          <startDate>1321033535125</startDate>
          <endDate>0</endDate>
          <repeatCount>0</repeatCount>
          <repeatInterval>10</repeatInterval>
          <schedulerTaskType>SOA_SERVICE</schedulerTaskType>
          <proxyURL>http://localhost:12000/</proxyURL>
          <creatorId>THECREATOR</creatorId>
      </scheduler:schedule>
    • Response Codes:
      • 201: Created
      • 400: Bad request made
  • Update a scheduler entry:
    • Request method: PUT
    • API URL: /scheduler/{connection-name}/{schedule-id}
    • Request payload example:
      <?xml version="1.0" encoding="UTF-8"?>
      <scheduler:schedule xmlns:atom="http://www.w3.org/2005/Atom" 
           xmlns:scheduler="http://www.ibm.com/optim/xsd/scheduler/9.1.0" 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
           xsi:schemaLocation="http://www.ibm.com/optim/xsd/scheduler/9.1.0 
           resource.xsd ">
        <id>fbf1cdd5-bdf7-4682-96ad-722672af0001</id>
          <serviceId>234d7245-aa47-44cb-b647-650734d200fd</serviceId>
          <startDate>1321033535125</startDate>
          <endDate>0</endDate>
          <repeatCount>0</repeatCount>
          <repeatInterval>10</repeatInterval>
          <schedulerTaskType>SOA_SERVICE</schedulerTaskType>
          <proxyURL>http://localhost:12000/</proxyURL>
          <creatorId>THECREATOR</creatorId>
      </scheduler:schedule>
    • Response Codes:
      • 200: OK
      • 400: Bad request made
      • 404: Not found
  • Remove a scheduler entry:
    • Request method: DELETE
    • API URL: /scheduler/{connection-name}/{schedule-id}
    • Response Codes:
      • 204: No content
      • 400: Bad request made
      • 404: Not found

Web client reference implementation

A reference implementation that showcases the interaction with the Optim Service Interface accompanies this article. This web client application was developed as a Java servlet named OsiClientSampleServlet and deployed as a web application to the path /osiClientSample on WebSphere® Application Server Community Edition that is running locally on port 8080. Consequently, for the purposes of this article, the URL to the reference implementation is http://localhost:8080/osiClientSample/OsiClientSampleServlet. The code for the OsiClientSampleServlet can be found in the Download section of this article.

The reference implementation provides functionality to display a list of all available Optim services including details, execute those Optim services, and then monitor those Optim services execution instances. It also provides the ability to purge individual Optim service execution instances. It does this by repeatedly following the simple paradigm detailed here:

  • Construct a URL that targets an OSI public RESTful API.
  • Construct an XML request payload, if necessary, based on the XSD of the specific RESTful API.
  • Issue an HTTP request with the appropriate HTTP method (GET, POST, PUT, or DELETE) using the constructed URL and request payload.
  • Process the HTTP response returned from the OSI public RESTful API by validating the HTTP response code and then, if necessary, manipulating the response payload based on the XSD of the specific RESTful API to suit your needs.
Figure 1. Reference implementation user interface
A web browser page displaying the reference implementation. A list of services to execute followed by a list of service instances that can be deleted along with refresh buttons for each list.

Displaying Optim Services

As described and shown in Figure 1, the reference implementation defined by the Java servlet code OsiClientSampleServlet.java performs a display of all available Optim services. It does this by first issuing an HTTP GET request to the base URI of the OSI Optim service request API. Once the HTTP response payload is processed a list of Optim service detail URL links is made available. This set of links is then processed one at a time, each issuing another HTTP GET request to the specified link. The response payload for each HTTP GET request is further processed and finally the Optim Services portion of the web page is rendered containing a list of all available Optim services by Service Path and Service Name.

Displaying Optim service monitoring

The display of Optim service monitoring information by the reference implementation is handled much in the same manner as is the display of Optim services information detailed earlier. First, an HTTP GET request is issued to the base URI of the OSI Optim service monitoring API. Once the HTTP response payload is processed, a list of Optim service execution instance detail URL links is made available. This set of links is then processed one a time, each issuing another HTTP GET request to the specific link. The response payload for each HTTP GET request is further processed. For each set of service execution instance details, a service id is extracted, and yet another HTTP GET request is initiated to the OSI, except this time it is to the Optim service request API, requesting Optim service detail for the provided service id. Once all this information is available, the Optim Service Monitoring portion of the web page is rendered. It contains a list of all available Optim service execution instances by Execution Id and Service Name, showing the start and end time for the execution as well as the return code of the execution.

Running a service

When any one of the Optim services listed on the web page is invoked for execution via the web page, the reference implementation in turn accepts the request and captures the service id that is to be used for execution. It then starts the process of constructing an XML request payload. First, an HTTP GET request is made to the OSI Optim Server API that returns a response containing a list of available Optim servers to execute on. For simplicity, the first Optim server on the returned list is used and added to the XML request payload. Next, another HTTP GET request is made to the OSI Optim service request API seeking Optim service details for the previously acquired service id. The returned HTTP response is then processed, and the XML request payload is completed with content from the response. At this point, an HTTP POST request is made to the OSI Optim service execution API to run the specified service. The XML request payload accompanies this POST request. Finally, the HTTP response for the POST request is processed and if service execution was successfully submitted, a message is displayed on the web page containing the execution id of the new service execution instance.

Purging a service execution instance

When an Optim service execution instance purge is invoked via the web page, the reference implementation in turn accepts the request and captures the execution id that is marked for deletion. It then makes an HTTP DELETE request to the OSI Service monitoring API, which contains the execution id acquired earlier. The HTTP response is then processed and validated for success. If successful, a message stating that the service execution instance purge request was completed is then displayed on the web page.


The OsiClientSampleServlet

We now take a look at the code of the reference implementation and provide a deeper and more granular description of how the code performs all of the functionality described earlier. Refer to the OsiClientSampleServlet.java code found in the Download section of this article.

OSI base URL

When the OSI is deployed to an application server, a base URL identifying the OSI is established. The OSI URL is dependent upon the application server's host and port as well as the OSI context root. The context root for the OSI is /server. So if your application server host is "localhost" and its port is 8080, then "http://localhost:8080/server" is the OSI base URL. In the case of the code sample, the OSI base URL has been hard coded as a constant (not recommended) that is referenced throughout the code.

private static String OSI_BASE_URL = "http://localhost:8080/server";

Optim directory connection

The Optim directory connection is the name to use for any HTTP request requiring a connection name. This defines the Optim directory that contains the services and service instances that are referenced in the application. Normally the Optim directory connection name would be retrieved using the OSI connection request API but in the case of our code sample, the Optim directory connection name is hard coded as a constant (not recommended) that is referenced throughout the code.

private static String OPTIM_DIR_CONNECTION = "OPTIMDIR";

Overridden HttpServlet methods

The OsiClientSampleServlet class is simply an extension of the javax.servlet.http.HttpServlet class. With that said, the doGet and doPost methods of the OsiClientSampleServlet override the HttpServlet method implementations with code that manages the flow of work in the OsiClientSampleServlet.

The doGet method

Because the GET request method is typically the default request method when issuing a request from a web browser, when the web client application URL of http://localhost:8080/osiClientSample/OsiClientSampleServlet is accessed via a web browser, the doGet method is the method that gets initially invoked, allowing the OsiClientSampleServlet to construct the page referenced earlier. High-level process logic follows:

  • Process the Optim Services details by invoking the displayServices method.
  • Process the Optim Service Monitoring details by invoking the displayMonitoring method.

The doPost method

The doPost method is invoked whenever a form with a POST request method assigned to it is submitted from the initial browser rendering and any subsequent browser renderings of http://localhost:8080/osiClientSample/OsiClientSampleServlet. All Run and Purge buttons on the web page are each part of their own POST method. High level process logic follows:

  • Process the Optim Services details by invoking the displayServices method.
  • If an Optim service identifier request parameter is provided, then invoke the executeService method to run the Optim service identified by the Optim service identifier provided. Essentially, this means that a Run button was pressed.
  • If a service execution instance identifier request parameter is provided, then invoke the removeServiceInstance method to delete the service execution instance identified by the service execution instance identifier provided. Essentially, this means that a Purge button was pressed.
  • Process the Optim Service Monitoring details by invoking the displayMonitoring method.

Helper methods

There are four methods included in OsiClientSampleServlet that are called multiple times to perform rudimentary tasks necessary for communication with the OSI, general response payload processing, and web page rendering. These methods are as follows:

The getHttpURLConnection method

This method establishes a communication channel between the OsiClientSampleServlet and the OSI via an http connection with a request type of GET, POST, PUT, or DELETE. High-level process logic follows:

  • Open the HTTP URL connection.
  • Set the appropriate request method for the connection.
  • Set the appropriate request headers.
  • Return the connection.

The createDOMFromResponse method

This method formats and returns the response input stream as a DOM. This provides the OsiClientSampleServlet the ability to parse the response payload, now represented by the DOM for specific elements based on an XSD specification. High level process logic follows:

  • Parse the response to a document.
  • Return the document.

The getTagsValue method

The getTagsValue method parses a DOM for a specific element based on a tag name defined in an XSD. High-level process logic follows:

  • Retrieve the list of nodes from the DOM identified by the requested element tag name.
  • Return the value of the first node in the list.

The displayPageHeader method

The displayPageHeader method constructs the opening web page HTML tags and defines the cascading style sheet used by the page.

The OSI Interfacing methods

The displayServices, displayMonitoring, executeService, and removeServiceInstance methods perform all of the heavy lifting for the OsiClientSampleServlet. They construct request payloads when necessary, send specific requests to the OSI, and process the returning responses and response payloads if necessary. Then, they use the data retrieved from the responses to either interrogate the OSI for more information or format the data for display to the web browser.

The displayServices method

The displayServices method gets the list of all available Optim services from the OSI. The list of services is then processed and details for each service are retrieved from the OSI. Finally, the retrieved OSI data is formatted and displayed. Figure 2 is an example of the output from this method. Logic follows.

Figure 2. Optim services
A portion of a the reference implementation displaying a list of services to execute.
  • Perform a GET request and retrieve the list of all available Optim services from the OSI:
    ...
    // Construct URL for retrieving a list of all Optim services from the OSI
    URL urlGetServiceList = new URL(String.format("%s/service/%s", OSI_BASE_URL, 
                                    OPTIM_DIR_CONNECTION));
    HttpURLConnection conn = null;
    // Issue a GET request to the OSI URL defined above
    conn = getHttpURLConnection(urlGetServiceList, "GET");
    ...
  • If the response status is OK (response code of 200), then extract the node list of Optim service links:
    ...
    if (conn.getResponseCode() == 200) {
       // For an OK (200) response status, process the response body into a DOM
       Document dom = createDOMFromResponse(conn.getInputStream(), 
                                            conn.getContentEncoding());
       NodeList nodeList = dom.getElementsByTagName("link");
    ...
  • Process the list of Optim service links by extracting each Optim service href link. Use that link to perform another GET request to the OSI that will retrieve the detail for the Optim service referenced on the href link.
    ...
    // Process all the Optim service URL links returned
    for (int i = 0; i < nodeList.getLength(); i++) {
       // Construct URL for retrieving Optim service details from the OSI
       String href;
       href = nodeList.item(i).getAttributes().getNamedItem("href").getNodeValue();
       URL urlGetService = new URL(href);
       conn = null;
       // Issue a GET request to the OSI URL defined above
       conn = getHttpURLConnection(urlGetService, "GET");
    ...
  • For each Optim service, check for an OK response status (response code of 200) and then format and display the service details (Service Id, Service Name, Service Path).
    ...
    if (conn.getResponseCode() == 200) {
       // For an OK (200) response status, process the response body content into a DOM
       dom = createDOMFromResponse(conn.getInputStream(), conn.getContentEncoding());
       // Extract service data from DOM and display content on web page
       String serviceId = getTagsValue(dom, "serviceId");
       String servicePath = getTagsValue(dom, "servicePath");
       String serviceName = getTagsValue(dom, "serviceName");
       display.println("<tr>");
       display.println("<td>" + servicePath + "</td><td>" + serviceName + "</td>");
       display.println("<td align='center'>);
       display.println("<form action='OsiClientSampleServlet' method='post'>");
       display.println("<input type='hidden' name='serviceId' value='" + serviceId);
       display.println("'/><input type='image' src='execute.png' alt='Run…'/>");
       display.println("</form></td></tr>");
    }
    ...

The displayMonitoring method

The displayMonitoring method gets the list of all Optim service execution instances from the OSI. The list of service execution instances is then processed, and details for each service execution as well as each service referenced in the service execution are retrieved from the OSI. Finally, the retrieved OSI data is formatted and displayed. Figure 3 is an example of the output from this method. Logic follows.

Figure 3. Optim service monitoring
A portion of a the reference implementation displaying a list of service instances. Each entry in the list includes execution id, service name, start and end time, return code and the ability to delete the service instance.
  • Perform a GET request and retrieve the list of all Optim services execution instances from the OSI:
    ...
    // Construct URL to retrieve all Optim service execution instances
    URL urlGetExecList = new URL(String.format("%s/monitor/%s", OSI_BASE_URL, 
                                 OPTIM_DIR_CONNECTION));
    HttpURLConnection conn = null;
    // Issue a GET request to the OSI URL defined above
    conn = getHttpURLConnection(urlGetExecList, "GET");
    ...
  • If the response status is OK (response code of 200), then extract the node list of Optim service execution instance links:
    ...
    if (conn.getResponseCode() == 200) {
       // For an OK (200) response status, process the response body into a DOM
       Document dom = createDOMFromResponse(conn.getInputStream(),
                                            conn.getContentEncoding());
       NodeList nodeList = dom.getElementsByTagName("link");
    ...
  • Process the list of Optim service execution instance links by extracting each Optim service execution instance href link. Use that link to perform another GET request to the OSI that will retrieve the detail for the Optim service execution instance referenced on the href link.
    ...
    // Process all the Optim service monitoring URL links returned
    for (int i = 0; i < nodeList.getLength(); i++) {
       // Construct URL for retrieving Optim service execution instance details
       String hrefLink;
       hrefLink = nodeList.item(i).getAttributes().getNamedItem("href").getNodeValue();
       URL urlGetExecInstance = new URL(hrefLink);
       conn = null;
       // Issue a GET request to the OSI URL defined above
       conn = getHttpURLConnection(urlGetExecInstance, "GET");
    ...
  • For each Optim service execution instance, check for an OK response status (response code of 200) and then format service execution instance fields:
    ...
    if (conn.getResponseCode() == 200) {
       // For an OK (200) response status, process the response body into a DOM
       dom = createDOMFromResponse(conn.getInputStream(), conn.getContentEncoding());
       // Extract service instance execution data from DOM and format fields
       String execId = getTagsValue(dom, "id");
       String serviceId = getTagsValue(dom, "serviceId");
       Format dateFormat = new SimpleDateFormat("MM/dd/yyyy HH:mm:ss");
       long startTime = Long.valueOf(getTagsValue(dom, "startTime")).longValue();
       String startDate = dateFormat.format(new Date(startTime)).toString();
       String endDate = null;
       String returnCode = null;
       if (getTagsValue(dom, "endTime") != null && 
           !getTagsValue(dom, "endTime").equals("0")) {
          long endTime = Long.valueOf(getTagsValue(dom, "endTime")).longValue();
          endDate = dateFormat.format(new Date(endTime)).toString();
          returnCode = getTagsValue(dom, "returnCode");
       } else {
          endDate = "EXECUTING...";
          returnCode = "--";
       }
    ...
  • For each Optim service execution instance, perform another GET request to the OSI that will retrieve the detail for the Optim service that is referenced in the Optim service execution instance.
    ...
    // Construct URL for retrieving Optim service details from the OSI
    URL urlGetService = new URL(String.format("%s/service/%s/%s", OSI_BASE_URL, 
                                OPTIM_DIR_CONNECTION, serviceId));
    conn = null;
    // Issue a GET request to the OSI URL defined above
    conn = getHttpURLConnection(urlGetService, "GET");
    ...
  • If the response status is OK (response code of 200), then format and display the service execution and Optim service details:
    ...
    if (conn.getResponseCode() == 200) {
       // For an OK (200) response status, process the response body into a DOM
       dom = createDOMFromResponse(conn.getInputStream(), conn.getContentEncoding());
       // Extract service data from DOM and display monitoring content on page
       serviceName = getTagsValue(dom, "serviceName");
       display.println("<tr><td>" + execId + "</td><td>" + serviceName + "</td>");
       display.println("<td>" + startDate + "</td><td>" + endDate + "</td>");
       display.println("<td align='center'>" + returnCode + "</td>");
       display.println("<td align='center'>");
       display.println("<form action='OsiClientSampleServlet' method='post'>");
       display.println("<input type='hidden' name='executionId' value='" + execId);
       display.println("'/><input type='image' src='purge.png' alt='Run...'/>");
       display.println("</form></td></tr>");
    }
    ...

The executeService method

The executeService method retrieves Optim server information as well as Optim service details from the OSI. This data is used to create a request payload, which is then sent to the OSI for service execution. The OSI service execution response is then formatted and displayed. Logic follows.

  • Perform a GET request and retrieve the list of all available Optim servers from the OSI:
    ...
    // Construct URL for retrieving Optim server details from the OSI
    URL urlGetServer = new URL(String.format("%s/runtime", 
                               OSI_BASE_URL));
    HttpURLConnection conn = null;
    // Issue a GET request to the OSI URL defined above
    conn = getHttpURLConnection(urlGetServer, "GET");
    ...
  • If the response status is OK (response code of 200), retrieve the first Optim server in the list of Optim servers and then perform another GET request from the OSI to retrieve the Optim service details for the Optim service identified by the provided service identifier:
    ...
    if (conn.getResponseCode() == 200) {
       // For an OK (200) response status, process the response body into a DOM
       Document dom = createDOMFromResponse(conn.getInputStream(), 
                                            conn.getContentEncoding());
       // Extract RSI URL data from DOM for use on the request payload
       String rsiURL = getTagsValue(dom, "rsiURL");
       // Construct URL for retrieving Optim service details from the OSI
       URL urlGetService = new URL(String.format("%s/service/%s/%s", OSI_BASE_URL, 
                                                 OPTIM_DIR_CONNECTION, serviceId));
       conn = null;
       // Issue a GET request to the OSI URL defined above
       conn = getHttpURLConnection(urlGetService, "GET");
    ...
  • If the response status is OK (response code of 200), then build the request payload based on the XSD definition to contain the service and Optim server specifics. Issue a POST request that contains the request payload to the OSI that executes the specified service using the specified Optim server.
    ...
    if (conn.getResponseCode() == 200) {
        // For an OK (200) response status, process the response body into a DOM
        dom = createDOMFromResponse(conn.getInputStream(), 
                                    conn.getContentEncoding());
        // Extract service data from DOM and construct the request payload
        String servicePath = getTagsValue(dom, "servicePath");
        String serviceName = getTagsValue(dom, "serviceName");
        StringBuilder payload = new StringBuilder();
        payload.append("<?xml version='1.0' encoding='UTF-8'?>");
        payload.append("<sem:serviceRequestExecutionInput ");
        payload.append("xmlns:sem='http://www.ibm.com/optim/xsd/sem/9.1.0' ");
        payload.append("xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' ");
        payload.append("xsi:schemaLocation='http://www.ibm.com/optim/xsd/sem/9.1.0 
                       resource.xsd '>");
        payload.append(String.format("<serviceId>%s</serviceId>", serviceId));
        payload.append(String.format("<serviceName>%s</serviceName>", serviceName));
        payload.append(String.format("<servicePath>%s</servicePath>", servicePath));
        payload.append(String.format("<rsiURL>%s</rsiURL>", rsiURL));
        payload.append("</sem:serviceRequestExecutionInput>");
        // Construct URL for executing an Optim service via the OSI
        URL urlExecuteService = new URL(String.format("%s/execute/%s/%s", OSI_BASE_URL, 
                                        OPTIM_DIR_CONNECTION, serviceId));
        conn = null;
        // Issue a POST request and stream the request payload to the OSI URL above
        conn = getHttpURLConnection(urlExecuteService, "POST");
        OutputStreamWriter outStreamWriter;
        outStreamWriter = new OutputStreamWriter(conn.getOutputStream());
        outStreamWriter.write(payload.toString());
        outStreamWriter.flush();
    ...
  • If the response status is ACCEPTED (response code of 202), then format and display the service execution identifier and message:
    ...
    if (conn.getResponseCode() == 202) {
        // For an ACCEPTED (202) response status, process the response body into a DOM
        dom = createDOMFromResponse(conn.getInputStream(), conn.getContentEncoding());
        // Extract service execution data from DOM and display content on page
        String execId = getTagsValue(dom, "executionId");
        display.println("<p>The service execution request has been accepted 
                         for the following:");
        display.println("<br><br>Service Name:");
        display.println("lt;b>" + serviceName + "</b><br>");
        display.println("Execution ID:");
        display.println("<b>" + execId + "</b></p>");
        display.println("<p>Click refresh to monitor the service execution below.</p>");
    }
    ...

The removeServiceInstance method

The removeServiceInstance method uses the provided service execution identifier to issue a deletion request to the OSI for the specified service execution instance. The method then formats and displays a deletion status message. Logic follows.

  • Perform a DELETE request to the OSI using a constructed URL containing a specific service execution instance identifier:
    ...
    // Construct URL for removing an Optim service execution instance
    URL urlDeleteServiceInstance = new URL(String.format("%s/monitor/%s/%s",  
                                           OSI_BASE_URL, OPTIM_DIR_CONNECTION, execId));
    HttpURLConnection conn = null;
    // Issue a DELETE request to the OSI URL defined above
    conn = getHttpURLConnection(urlDeleteServiceInstance, "DELETE");
    ...
  • If the response status is NO CONTENT (response code of 204), then a successful deletion of the service execution instance has occurred, so format and display deletion success message.
    ...
    if (conn.getResponseCode() == 204) {
       // For a NO CONTENT (204) response status, display successful deletion
       display.println("<p>Service instance " + execId + " has been removed.</p>");
    }
    ...

Summary

This article presents a process that depicts the communication between a web client application and the OSI. This process is repeatable and can be replicated easily. Sample code further illustrates the repeatable nature of this process, along with documentation detailing the process step-by-step as it exists in various parts of the sample code. Armed with this article and the accompanying sample code, you should now have a head-start toward the implementation of a custom Optim user experience that utilizes the Optim Service Interface.


Downloads

DescriptionNameSize
Web client implementation project zip.dm-1311optimservcom.ibm.nex.osi.example.app.zip649KB
OsiClientSample.java sample codedm-1311optimservOsiClientSample.zip6KB
OSI RESTful API Roadmaps (.xsd/.wadl)dm-1311optimservosi-xsd-wadl-reference.zip11KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=953891
ArticleTitle=Optim Service Interface usage guide
publish-date=11212013