Oracle Cloud Infrastructure Node.js/TypeScript Client for Work Requests

Common errors

• Error: NotAuthenticated: The required information to complete authentication was not supplied.

  cause The authentication details provider could not find valid credentials (e.g., `~/.oci/config` file missing or malformed, environment variables not set).
  fix Verify your OCI configuration file (`~/.oci/config`) exists and is correctly formatted, or ensure environment variables like `OCI_CLI_PROFILE` and `OCI_CLI_CONFIG_FILE` are set if using a non-default profile/location.

• Error: ServiceError: Authorization failed or requested resource not found. (opc-request-id: <request-id>)

  cause The authenticated user lacks the necessary IAM policies to perform the requested operation, or the specified resource (e.g., compartmentId) does not exist or is incorrect.
  fix Check your OCI IAM policies to ensure the user or instance principal has permissions for the Work Requests service. Double-check the OCIDs used in your request for correctness.

• TypeError: Cannot read properties of undefined (reading 'WorkRequestsClient')

  cause Incorrect import statement or `oci-workrequests` package not installed or incorrectly resolved by Node.js/TypeScript.
  fix Ensure `npm install oci-workrequests` has been run successfully and your import statement is `import { WorkRequestsClient } from 'oci-workrequests';`.

Warnings

• gotcha OCI SDK authentication can be complex, requiring a correctly configured `~/.oci/config` file, instance principals for compute instances, or session tokens for Cloud Shell. Incorrect setup is a common source of errors.
  Fix: Ensure your `~/.oci/config` file is properly configured with `user`, `fingerprint`, `key_file`, and `tenancy` details, or ensure your compute instance has appropriate instance principal policies.
• breaking Major version updates to the overall OCI SDK (e.g., from v2 to v3) often involve significant changes to module structure, authentication patterns, or API interfaces, requiring code adjustments.
  Fix: Always review the release notes for the main `oci-typescript-sdk` repository before upgrading major versions. Pin exact major versions in your `package.json` to avoid unexpected breaking changes.
• gotcha The `oci-workrequests` package (and other service-specific packages) receives very frequent updates. While this brings new features, it can also introduce subtle behavior changes or dependency conflicts if not managed carefully.
  Fix: Regularly update your dependencies and test thoroughly. Consider using a dependency management tool that allows for minor version updates (`^2.130.0`) but prevents major shifts, or pin specific versions if stability is paramount.
• gotcha OCI API calls, especially for listing operations, often require a `compartmentId`. Forgetting this or providing an incorrect OCID will result in unauthorized or not found errors.
  Fix: Always ensure the required `compartmentId` is provided in request objects and that the provided OCID is correct and accessible by the authenticated user.

Install

• npm install oci-workrequests npm
• yarn add oci-workrequests yarn
• pnpm add oci-workrequests pnpm

Imports

• WorkRequestsClient
  wrong:

  const WorkRequestsClient = require('oci-workrequests');

  correct:

  import { WorkRequestsClient } from 'oci-workrequests';

  The OCI SDK primarily targets modern TypeScript/ESM environments. While CommonJS might work with transpilation, direct require is less common and types will be lost.
• common
  wrong:

  import common from 'oci-common';

  correct:

  import * as common from 'oci-common';

  The `oci-common` module exports many utilities, including authentication providers, as named exports. It's typically imported as a namespace.
• ListWorkRequestsRequest

  import { requests } from 'oci-workrequests';
  const request: requests.ListWorkRequestsRequest = { /* ... */ };

  Request and response types for service operations are typically nested under a 'requests' or 'responses' namespace within the service module.

Quickstart

This code initializes the WorkRequests client and lists the first 10 work requests in a specified compartment, demonstrating basic API interaction.

import { WorkRequestsClient } from 'oci-workrequests';
import * as common from 'oci-common';
import { requests } from 'oci-workrequests';

async function listAllWorkRequests(): Promise<void> {
  try {
    // Configure authentication using default provider (e.g., OCI config file or instance principal)
    const provider = new common.auth.DefaultAuthenticationDetailsProvider();
    
    // Initialize the WorkRequests client
    const client = new WorkRequestsClient({
      authenticationDetailsProvider: provider
    });

    // Define the request to list work requests
    // Replace 'ocid1.compartment.oc1..aaaaaaaaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' with your compartment OCID
    const listRequest: requests.ListWorkRequestsRequest = {
      compartmentId: process.env.OCI_COMPARTMENT_ID ?? 'ocid1.compartment.oc1..aaaaaaaaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx',
      // You can add filters like status, resourceId, etc.
      limit: 10 // Limit to 10 results for brevity
    };

    // Call the ListWorkRequests API
    console.log('Listing OCI Work Requests...');
    let response = await client.listWorkRequests(listRequest);
    
    if (response.items && response.items.length > 0) {
      console.log(`Found ${response.items.length} work requests:`)
      for (const wr of response.items) {
        console.log(`  ID: ${wr.id}, Status: ${wr.status}, Resource: ${wr.resources ? wr.resources[0]?.identifier : 'N/A'}`);
      }
    } else {
      console.log('No work requests found in the specified compartment.');
    }

  } catch (error) {
    console.error('Error listing work requests:', error);
  }
}

listAllWorkRequests();