Production engineering · Advanced

APIs, JSON & integration

Expose business logic and connect systems with explicit contracts and reliable failure handling.

Learn this topic first: Production engineering: debug, secure, integrate and tune →

6 explained questions · 5 practice MCQs

Questions and answers

1. How can an RPG application expose a service? (Intermediate)

Options include a supported Integrated Web Services deployment over suitable program/procedure interfaces or an application service layer that calls IBM i business logic. The choice depends on the contract, installed versions, security, and operational needs.

Separate HTTP concerns from reusable business procedures. Define request types, validation, response/error mapping, authentication, and transaction boundaries. Wrapping a program with HTTP does not automatically make screen-oriented global-state logic safe for concurrent requests.

2. What should you check before calling an IBM i API? (Intermediate)

Read the API’s exact prototype, required and optional parameter groups, qualified-name format, buffer lengths, and error-code structure. Many APIs use structured receiver formats with offsets and sizes; treating them as arbitrary strings is unsafe.

Allocate enough storage, initialize lengths correctly, and check returned bytes/diagnostics before reading fields. Use a supported format version and handle additional returned data without assuming a fixed layout copied from an old example.

3. Why do CCSIDs matter in integrations? (Intermediate)

CCSIDs identify character encoding interpretations. IBM i applications often exchange data between EBCDIC-oriented database fields and UTF-8-oriented web or stream interfaces. Incorrect conversion can corrupt punctuation, non-ASCII names, or JSON syntax.

Define encoding at each boundary and test multilingual content. Distinguish binary data from text; blindly translating binary payloads damages them. A transfer completing successfully does not prove the received bytes represent the intended characters.

4. How should an API handle retries and timeouts? (Advanced)

Set bounded connection and operation timeouts, classify retryable failures, and use backoff rather than immediate unbounded loops. A timeout means the client did not receive a timely result; it does not prove the server performed no work.

Use an idempotency key for operations such as posting payments and expose a way to retrieve the prior result. Record correlation identifiers across IBM i and the external service. Avoid holding database locks while waiting through long network retries.

5. How should JSON be parsed and validated? (Advanced)

Use a structured parser or supported SQL JSON facilities instead of substring slicing. Validate required fields, types, lengths, ranges, and the business meaning of identifiers. Distinguish missing, null, and empty string values.

Return predictable validation errors without exposing implementation internals. Test nested objects, escaped characters, unexpected fields, and large payload limits. Successful parsing only proves syntactic validity; it does not authorize the requested business action.

6. How do you design an integration that survives partial failure? (Advanced)

Write the local business change and durable outbound intent together when they share a database transaction. Dispatch independently, track delivery attempts, and make the receiver idempotent. Reconcile ambiguous outcomes using stable operation identifiers.

Define ownership of retries, compensation, and manual resolution. A local COMMIT cannot guarantee that a remote ERP or payment provider has committed the matching action. Expose operational states such as pending, delivered, rejected, and requires review rather than a single misleading success flag.

Practice checkpoint

  1. 1. What does a network timeout prove?
    1. The server certainly rolled back
    2. The client did not receive a timely response
    3. The request was never received
    4. The operation must be safe to duplicate
  2. 2. What prevents duplicate effects on retry?
    1. A different random key for every retry
    2. A larger payload
    3. An idempotency key with stored outcome handling
    4. Only a longer timeout
  3. 3. Why check an API receiver length?
    1. To increase job priority
    2. To select a printer
    3. To change the library list
    4. To avoid reading beyond valid returned data
  4. 4. Which method is appropriate for JSON?
    1. A structured parser plus schema/business validation
    2. Splitting only on commas
    3. Replacing quotes manually
    4. Assuming ASCII always
  5. 5. What needs explicit definition at text boundaries?
    1. Only file extension
    2. Encoding/CCSID conversion
    3. Only subsystem name
    4. Only job queue priority
Show answer key and explanations

1. B — The client did not receive a timely response Reconcile outcomes before retrying non-idempotent work.

2. C — An idempotency key with stored outcome handling The same business operation must be recognized across repeated deliveries.

3. D — To avoid reading beyond valid returned data Structured APIs have buffer-size and returned-data contracts.

4. A — A structured parser plus schema/business validation JSON nesting and escaping require proper parsing, followed by validation.

5. B — Encoding/CCSID conversion Correct transfer of bytes is different from correct interpretation of text.

IBM documentation and further reading