IBM i Insurance Integration

Skip key takeaways

Updated October 8, 2026

• Split channel traffic by direction Writes go through the programs that already change policies correctly, while reads come from SQL interfaces or a journal-fed read store, so a quote campaign never competes with endorsements for the same jobs and locks.
• Keep endorsements and payments in the existing programs Expose RPG or COBOL transaction programs through Integrated Web Services so rating and business rules run once, and pass effective dates as validated character or numeric fields because PCML cannot carry Date or Timestamp.
• Design service hours around the batch window Collect the nightly job schedule and the files each job locks before promising 24-hour self-service, then decide per endpoint whether writes queue or are refused during the batch run.
• Fix CCSID settings and decimal handling before exposure A job at CCSID 65535 can break parameter conversion and a column tagged 65535 returns bytes instead of text. Premiums and limits must cross the boundary as exact decimals checked against the field's digits, never as floating point.
• Treat journal receiver retention as a CDC operations rule The Debezium IBM i connector is still incubating and needs a manual resync if a receiver is deleted before it is read, so receiver cleanup must check the consumer's confirmed position first.

Copy takeaways

In short: IBM i insurance integration gives mobile quote, policyholder portal, broker API, payment and analytics channels access to a policy administration system on IBM i (AS/400) without rewriting it. The split that holds up is by direction. Endorsements, payments and cancellations go through the existing RPG or COBOL transaction programs, exposed as REST services by Integrated Web Services (IWS), so rating and business rules still run where they live. High-volume reads come from SQL interfaces or a journal-fed read store, and events leave through data queues bridged to a broker. The risks concentrate at the boundary, where documented IBM i constraints and the nightly batch cycle meet channel conventions: dates, encoding, packed decimals, locks and batch windows.

The guide assumes IBM i stays the system of record. Features arrive through PTFs, so check each mechanism against the release you run.

Which IBM i Mechanism Serves Which Insurance Channel?

Insurance channels differ less in their screens than in what they do to the policy record. A quote reads rating tables, while an endorsement changes an in-force contract. The table pairs each need with the IBM i mechanism that suits its direction. This pairing is Pharos Production's own engineering framing, not an IBM reference architecture, and the last column lists the risk that follows from each mechanism's documented constraints rather than incidents from a specific engagement.

Channel need	IBM i mechanism	What it exposes	Typical failure mode
Mobile quote and premium indication	IWS REST service over the existing rating program	Rating program parameters as a JSON resource	Campaign traffic queues behind interactive and batch work on the same programs
Policyholder portal reads	IWS SQL statements as web APIs (IBM i 7.2 and later) or a read store fed by CDC	Result sets from Db2 for i, or a portal-shaped copy	Wide queries collide with the nightly batch and show a half-applied renewal
Agent and broker APIs	Stored procedures called over JDBC through JTOpen, or through Mapepire (a Technology Preview since August 2024)	Typed parameters plus variable-size result sets	Broker polling multiplies connections, or a preview-stage component ends up carrying production traffic
Endorsements, cancellations and reinstatements	IWS REST over the existing RPG or COBOL transaction programs, described by PCML	Program parameters as REST operations, rules intact	PCML cannot carry Date, Time or Timestamp, so effective dates cross as character or numeric fields and a format slip misdates the change
Payments to a gateway and webhooks to partners	QSYS2 HTTP functions, which are outbound calls from IBM i	SQL functions that send HTTP requests to external services	A gateway timeout leaves the payment state unknown, or the functions get mistaken for a way to read Db2 for i
Business events for new channels	Data queues bridged to an event broker	Free-format messages written by RPG programs or by SQL procedures	A program change alters the message layout and the bridge keeps decoding the old one
Analytics feeds and a read store	Journal-based CDC, for example the Debezium IBM i connector, which is still incubating	Row-level changes read from the journal, with before and after images	Journal receivers deleted before the connector reads them force a full resync

A read can be served from any sufficiently fresh copy. A write has to pass through the code that already knows how to change a policy correctly.

Why Do Endorsements, Payments and Cancellations Stay in the Existing Programs?

On a mature policy administration system an endorsement is not an update to a row. The program that processes it re-rates the policy, prorates premium, writes history and adjusts commission, often across many files that only that program updates in a consistent order. A service that writes the files directly duplicates all of that, and the copy drifts with every change the RPG team ships. Calling the existing program keeps one implementation of the rules, the same logic our insurance rating engine guide applies to premium calculation.

That reasoning assumes the policy programs are your own RPG or COBOL. When the policy administration system is a licensed vendor package running on IBM i, whether you may wrap a program, add an interface procedure or call an internal program directly depends on the license and the vendor's support terms, and an unsupported change can cost you upgrades. The vendor may also ship its own API layer, in which case writes go through that layer instead of IWS over the vendor's programs, and the questions in this section become questions for the vendor.

Two constraints shape how a policy transaction program gets exposed through Integrated Web Services, which IBM's product page says is used "to externalize ILE business logic as a service or API that can be called by various client implementations". Per IBM's IWS frequently asked questions, "The deploying of ILE programs as web services is dependent on a Program Call Markup Language (PCML) document describing the procedures to be externalized as web service operations." The same page lists what PCML cannot describe: "The following data types are not supported by PCML: Date, Time, Timestamp, Pointers, 1-Byte integers, and 8-byte unsigned integers". The FAQ also caps parameter counts by release and allows only 4-byte integers as return values and as parameters passed by value.

In insurance the date limit bites, because every endorsement and cancellation carries an effective date. The wrapper accepts an ISO 8601 date, validates it and converts it to the character or numeric format the program expects, rejecting anything ambiguous before the call. Time zone needs an explicit rule too, since midnight in the policy's jurisdiction is not midnight on the server. The cost of a slip is concrete: a cancellation or endorsement dated one day off can leave cover in force, or out of force, on the date of a claim, and the proration the program computes from that date produces a wrong premium or refund.

IBM's IWS REST tutorial, part 3 maps HTTP methods to procedures and notes: "In addition, you can set a URI path template for the resource." It also shows a program parameter used as the HTTP status code. Use that parameter so a rule rejection, a lock timeout and a program failure return different statuses, or the channel cannot tell a declined endorsement from one worth retrying.

Commitment control and record locks

Exposing a program does not make it atomic. IBM Redbooks SG24-8185, Modernizing IBM i Applications (First Edition, 2014) walks through implementing commitment control with every table on one journal, noting in that walkthrough that "Commitment control requires that the tables that are involved in the transaction that is being committed are all attached to the same journal." Its general definition of a transaction is wider and covers database files on the local system assigned to more than one journal, adding that "Each journal can be thought of as a local location." Older programs often update files one at a time, so a failed call can leave a policy half changed. Before exposure, list the files each program updates, confirm every one is journaled (one shared journal is the simplest setup) and decide between commitment control and a compensating step.

The same Redbook shows uncommitted rows held under update locks until commit or rollback, listed with the Display Record Locks command. A service call that holds locks while waiting on something slow blocks the green-screen user and the batch job that need the same policy. Keep calls short and give the wrapper a lock wait shorter than the channel's timeout.

Payments go out through the QSYS2 HTTP functions

When IBM i has to call a payment gateway or post a webhook, SQL can make the request. IBM's page on the QSYS2 HTTP functions says "These functions allow the SQL programmer to use Representational State Transfer (RESTful) via SQL, including Embedded SQL."

A payment call can time out with the charge already taken, so record the intent and an idempotency key in a committed row before the call and reconcile anything left pending against the gateway. HTTPS from these functions depends on the gateway's CA certificates in the Digital Certificate Manager *SYSTEM store, or a keystore named on the sslCertificateStoreFile option, and on read authority to that store for the calling profile, per IBM's TLS configuration note for the QSYS2 HTTP functions; the sslTolerate option it describes is for development and testing only.

Batch Windows, Nightly Jobs and In-Force Policies

A policy administration system on IBM i usually runs a nightly cycle of renewals, billing, commissions and month-end accounting while a mobile app expects to work at any hour. The integration decides per operation what happens during the batch window: reads continue from the read store, and writes are either queued or refused with a retry time.

Queued writes need care with in-force policies. An endorsement accepted at 23:00 and applied at 03:00 may land after the billing run has invoiced the old premium, which the existing program handles with an adjustment only if the endorsement goes through it. Every write should carry the policy version the channel last saw, so a stale endorsement is rejected instead of overwriting an underwriter's green-screen change.

Collect the job schedule and the files each job locks, then set each endpoint's service hours before any channel promises 24-hour self-service.

How Do You Offload Read Traffic for Mobile Quotes and Portals?

Policyholders open the app far more often than they change a policy, so reads need a path that does not compete with transaction programs. For simple lookups, IBM's IWS technology update table lists "SQL statements as web APIs" as a server enhancement from IBM i 7.2. It suits narrow, indexed reads such as claim status, while joins and paging belong in a stored procedure.

The 2014 Redbook SG24-8185 makes the case for procedures over JDBC: "Although JDBC enables you to use SQL SELECT and INSERT statements, it also allows you to do much more, including the invocation of SQL stored procedures." Java clients usually call them through JTOpen. Other runtimes can use Mapepire, which became available as a Technology Preview on 30 August 2024, so keep it off paths that cannot tolerate a preview-stage component.

The heaviest read traffic belongs on a journal-fed read store, so a renewal-season login spike never reaches the policy files. Bound quotes are the exception: an indication can come from cached rating tables, but the bound price comes from the rating program.

CCSID, EBCDIC and Packed Decimal at the Boundary

Legacy policy files on IBM i usually store character data in EBCDIC under a coded character set identifier (CCSID), and every channel speaks UTF-8. IWS and the JDBC driver convert automatically when the CCSIDs are right. The same conversion has long been built into the IBM i web stack: the 2014 Redbook SG24-8185 describes the CGI interface of IBM HTTP Server for i as "including the conversion between the ASCII character set that is commonly used for web pages and the EBCDIC character set that is used on IBM i". The trap is CCSID 65535, which marks data as binary and switches conversion off. Writing about the XMLSERVICE toolkit, the same Redbook says: "However, IBM i CCSID 65535 (hex) destroys the entire XMLSERVICE scheme."

CCSID 65535 bites in two places. A job running under CCSID 65535, which a profile inherits when the QCCSID system value is 65535 and the profile sets no CCSID of its own, can break the conversion of character parameters on program-call paths, and the Redbook reports hangs and junk data for the XMLSERVICE toolkit, so set a real CCSID on the system value (CHGSYSVAL QCCSID) or on every service and channel user profile (CHGUSRPRF CCSID), as the Redbook's XMLSERVICE section recommends, then restart the affected jobs. Columns tagged 65535 return bytes rather than text: find them before exposure and fix the tagging or convert per field. Then test round trips with accented names, since a character a channel accepts may have no equivalent in the file's EBCDIC code page.

Money and rates are usually packed or zoned decimal, declared with fixed digits and decimals. JTOpen (the open-source IBM Toolbox for Java) handles both exactly, and SG24-8185 notes that "the AS400ZonedDecimal class maps a zoned decimal to the Java BigDecimal". Premiums and limits never pass through a floating-point type: JSON carries them as strings or exact decimals, and the wrapper rejects a value that exceeds the field's digits instead of letting the program truncate it.

Events and Analytics Feeds: Data Queues and Journal-Based CDC

New channels need to know when a policy was issued or a payment applied. IBM i offers two native sources, one the application writes deliberately and one the database writes for every change.

Data queues bridged to a broker

The 2014 Redbook SG24-8185 states that "A data queue is a powerful program-to-program interface." It adds that "Messages on a data queue are in free format." Free format is the integration risk. A data queue message has no field definitions, so the bridge must know the layout, and a program change that inserts or resizes a field shifts every offset after it. Version the layout inside the message and make the bridge reject a version it does not know.

SQL can write to a data queue too. IBM's SEND_DATA_QUEUE technology update, for IBM i 7.3 and later, says the procedure "provides function similar to the Send Data Queue (QSNDDTAQ) API." A bridge job, typically Java on JTOpen, publishes each message to the broker. Our own design rule is to assume the message and the database commit can disagree, so each message carries the policy key and version and consumers that need certainty re-read the record.

Journal-based CDC into a read store

Per SG24-8185, First Edition, 2014: "When a table is attached to a journal, the database manager records a copy of every row in the table that is added updated or deleted." It also notes "You can choose to record before images, after images, or both before and after images." A consumer that needs the pre-change row, for example to emit a before state or to catch a changed key, needs before images, so shops that turned them off for performance should check what their CDC consumer expects before relying on after images alone.

Debezium added an IBM i connector in its 2.6.0.Beta1 release of March 2024. The connector's repository describes itself as incubating, and its README lists limitations including "No support for remote journals and fail over". Its troubleshooting note is explicit about images: if no journal entries arrive, "check journalling is enabled and set to *BOTH", so shops that turned before images off for performance need them back on for this connector. It warns that "the journal entries for table changes are not documented so rely on fetching table structure at runtime and refetching when table change detected", so every file change needs a CDC test of its own. On receivers: "If the journal is deleted before it is read it will log an error" and "At this point you really need to resync, this does not happen automatically".

Receiver retention is therefore an operations rule. The job that deletes old receivers checks the consumer's confirmed position first. Purge jobs delete rows the read store must also drop, and the apply step upserts idempotently on policy key and journal sequence, so a replay after a restart changes nothing.

Continuous replication for channels is a different job from a one-time move. Our legacy data migration strategy guide covers log-based CDC for a cut-over, where the switch waits for a confirmed log position. Here the feed never ends, so lag is monitored as a service level and balances show an as-of time.

Securing the Integration: Exit Points, User Profiles and TLS

Every new interface opens a path the green-screen menus used to guard. IBM Redbooks SG24-7680, Security Guide for IBM i V6.1 explains the control point: "An exit program is a program to which the exit point passes control." An exit program on the database servers can limit which profiles connect from which addresses.

Each channel runs under its own user profile with authority only to the programs and procedures it calls, never with *ALLOBJ special authority. The V6.1 guide adds that "If you have selected the event, the system writes a journal entry in the current journal receiver for the security auditing journal (QAUDJRN)." Those entries, like the history rows a policy program writes, typically name the profile the job ran under, so every portal endorsement reads as the portal's. Producer of record, commission and audit need the acting agent or policyholder identity, authenticated at the gateway, passed as a parameter into the transaction program and written with the change. IWS can also run a service under the authenticated user ID, which suits agents and underwriters who hold IBM i profiles. Policyholders do not hold them, so the parameter route remains the general one.

Terminate public traffic at a gateway and keep IBM i interfaces on a private network with TLS end to end. IBM's technology update table lists HSTS and CORS support for the IWS server from IBM i 7.3, and Mapepire's server installation guide covers TLS certificates and IP filtering by exit point.

Testing Against Green-Screen Behavior and Knowing When to Strangle

The green screen is the specification nobody wrote down. The 2014 Redbook SG24-8185 observes that "The flow and how a user might want to interact with an interface from a mobile or web perspective might be different from how the application is interacted with by using the green screen flow." A mobile flow that skips a screen can skip a validation that lived in the screen program.

A reliable test compares outcomes, not screens. Run the same endorsement through the 5250 flow and through the API on a copy of production data, then compare the resulting records field by field: premium, history rows, commission and the journal entries both paths produced. Any difference is a validation the API missed or a screen-side rule that belongs in a shared program.

Wrapping is not always the answer. When new products need rating logic the existing programs cannot express, when the batch window cannot shrink enough for the service hours the business wants or when every channel request means another round of PCML rework, the better path is to replace functions one at a time behind the same API. Our legacy modernization guide covers the strangler fig pattern for that move, and the channel API layer becomes its seam.

How Pharos Production Helps

Pharos Production's insurance software development team integrates legacy AS/400 systems via SOAP, REST, file-based batch and event-driven middleware, with an abstraction layer that isolates the product layer from the core so new products do not wait on the core's release cycle.

Our IBM i figure comes from a logistics engagement, not an insurance one. On the legacy modernization side, a REST wrapper with an event bus over a logistics enterprise's AS/400 order system cut new channel onboarding from 14 weeks to 6 days while the AS/400 stayed the system of record. Our insurance industry overview covers legacy core integration as one part of the wider insurance software picture.

Sources: IBM Support, Integrated Web Services for IBM i - Web services made easy, Integrated Web Services for IBM i - Frequently asked questions, Integrated Web Services for IBM i Technology Updates, Building a REST service with integrated web services server for IBM i: Part 3, New HTTP functions based in QSYS2, QSYS2.SEND_DATA_QUEUE() and Configuring IBM i DB2 QSYS2 HTTP Functions for TLS/HTTPS; IBM Redbooks, SG24-8185 Modernizing IBM i Applications from the Database up to the User Interface and Everything in Between, First Edition (June 2014) and SG24-7680 Security Guide for IBM i V6.1; Debezium project, debezium-connector-ibmi and Debezium 2.6.0.Beta1 release notes; Mapepire project, Why Mapepire? and Server Install/Config; IBM, JTOpen. Engineering guidance, not legal advice.

FAQ

Last updated: October 8, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• Can we integrate if the policy administration system is a licensed vendor package?

  Featured question. Copy link Copies a direct link to this answer to your clipboard.

  Usually, but the license decides the write path. Whether you may wrap, change or directly call the vendor's programs depends on the license and support terms, and an unsupported change can block future upgrades.

  If the vendor ships its own API layer, writes go through it. Reads from SQL interfaces or a journal-fed read store still depend on the vendor's file layouts, which can change with each vendor release.

• Is SOAP still needed for IBM i integration?

  Copy link Copies a direct link to this answer to your clipboard.

  Not for new channels, since the Integrated Web Services server supports REST. SOAP endpoints already in use by brokers, aggregators or older portals usually stay, because replacing them means coordinating with every external party that calls them.

  New services can be REST while the older SOAP contracts keep running beside them.

• Do RPG developers need to change programs before they can be exposed as APIs?

  Copy link Copies a direct link to this answer to your clipboard.

  Often a little. Programs with more parameters than the release allows, date-typed parameters, parameters passed by value other than 4-byte integers or interactive logic mixed into the transaction code need a thin wrapper program or procedure with a clean, PCML-friendly interface.

  The business logic itself stays as it is, which is the point of the approach.

• How do we keep the agent of record when channels share a service profile?

  Copy link Copies a direct link to this answer to your clipboard.

  Pass the identity explicitly. A job running under a channel's service profile typically records that profile in policy history and in the QAUDJRN audit journal, so the gateway authenticates the agent or policyholder and the wrapper passes that identity as a parameter the transaction program writes with the change.

  Producer of record and commission logic then read the passed identity, not the job's user profile. Agents and underwriters with their own IBM i profiles can instead be served by an IWS service that runs under the authenticated user ID, an option IBM lists from IBM i 7.2.

• Should an insurer move off IBM i before building new digital channels?

  Copy link Copies a direct link to this answer to your clipboard.

  Rarely as a first step. A platform replacement puts every in-force policy through a data migration, while new channels can run on top of the existing core in the meantime.

  The API layer built for those channels is also the seam a later, function-by-function replacement would use.

• Who should own the integration layer?

  Copy link Copies a direct link to this answer to your clipboard.

  A team that includes at least one engineer who reads RPG and understands the policy files, plus the API and channel engineers. The risks that follow from IBM i's documented constraints concentrate where the two worlds meet, in dates, encodings, decimals and locks, so splitting ownership along that line leaves the hardest problems with nobody.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.