Real-Time Parts Release API on Informatica CAI With Zero Custom Services
We built a secure REST API on Informatica Cloud Application Integration that tells a field engineer, in one call, whether a spare part can be released.
0
custom services to host, secure, or patch
4
clear outcomes from one call
1
secured endpoint for the whole flow
O V E R V I E W
Field engineers waiting on stock and contract checks done by hand
Our client is a field service and distribution business whose engineers need spare parts released on site. Stock sits across three depots, and the contract terms that decide whether a part is free or chargeable sit in a separate table.
Answering one engineer meant checking several places by hand, and the result depended on who looked it up. The usual fix, a small custom service for part lookup and another for pricing, would have added more code to host, secure, monitor, and patch. The client partnered with Ksolves to build one API that returns the release decision in real time, reads the data directly, and runs no separate service code.
C H A L L E N G E
01
Slow Release Decisions: Stock sat across three depots and contract terms in another table, so one answer meant checking several places by hand.02
A Custom Service for Every Lookup: The first design needed separate Python services for part lookup and pricing, each to be hosted, secured, and supported.03
Inconsistent Contract Rules: Whether a part was covered by the customer’s contract, or chargeable depended on who looked it up.04
Exposed Stock and Pricing Data: An API that returns stock and prices could not be left open to anyone who asks.05
Answers With No Next Step: A plain “not available” gave the engineer no bin, charge, or reason, and sent them back to the phone.06
Platform Traps That Look Correct: The obvious connector type, familiar expression syntax, a batch pricing task, and quoted values all looked fine at first and failed under real requests.S O L U T I O N
One governed CAI process that looks up, decides, and answers in a single call
Ksolves built the release API as 1 published process on Informatica Cloud Application Integration. It reads 4 MySQL tables through 4 data actions on one connector, routes every request to 1 of 4 outcomes, and runs behind one secured endpoint. Each fix below answers the challenge with the same number.
- 01 One call, one answer: A single synchronous request runs three lookups and a decision, and returns the result in the same call. Nothing is queued and nobody is called.
- 02 Data Access Service connector: The “Data Access Service Connector using Form” runs SQL against MySQL directly over JDBC. Its four actions, getPart, checkStock, checkContract, and getPrice, replaced both Python services.
- 03 Rules in one Decision step: Part existence, depot stock and contract coverage are checked in a fixed order every time. The formula is built from inserted fields in CAI’s XPath-style syntax, never typed by hand.
- 04 Secured by default: The published REST endpoint rejects requests without credentials with a 401 and processes requests with valid Basic Authentication.
- 05 Actionable outcomes: APPROVED returns the bin and a charge of 0. APPROVED_CHARGEABLE returns the charge and a quote reference. REFER names a depot to try, and NOTFOUND gives the reason.
- 06 Build choices checked against real requests: Pricing stays inside the request through getPrice instead of an asynchronous CDI task, and runs only on the chargeable path. Literal quotes were removed from all four outcome branches, and the JSON was rechecked in Postman and the Process Server Console.
- 07 Ready for other teams: A Swagger/OpenAPI file is generated at publish time so other teams can integrate without guessing, and the console keeps a step-by-step run history for every request.
Architecture
Technology stack
| Category | Technology |
|---|---|
| Platform | Informatica Cloud Application Integration (CAI) |
| Orchestration | Published CAI process with a Decision step and four outcome paths |
| Database | MySQL (part_master, part_stock, contract_entitlement, release_log) |
| Integration | Data Access Service Connector over JDBC, four data actions |
| Runtime | Self-managed Informatica Secure Agent |
| Security and API | REST endpoint with Basic Authentication, Swagger/OpenAPI generated at publish |
D E L I V E R Y
How one release request moves from tablet to answer
The client gets one endpoint instead of a chain of services: one Data Access Service connector, four data actions, one Decision step and a generated OpenAPI file. In the covered case, an engineer asks to release part PMP-3300 for customer CUST-1002 from depot DEP-PN. The process looks up the part, checks stock at the depot and checks the contract, then routes to APPROVED and returns a charge of 0 and the bin in the same call.
A part the contract does not cover, such as SNS-5500, takes the chargeable path and returns a charge of 180.00 with quote reference QT-SNS-5500. A part with no stock at the depot, such as FLT-2200, returns REFER with a depot to try. An unknown part, such as XXX-9999, returns NOTFOUND with a reason. Each path is checked with a real request against the published endpoint.
R E S U L T S
From manual checks to a release decision in one call
Engineers moved from waiting on someone to check stock and contracts to getting an answer they can act on on the spot. Ksolves replaced manual stock and contract checks, and a planned set of custom services, with one secured API on Informatica CAI. Every request is decided the same way and returns the bin, the charge, or the reason in a single call. Connecting a client’s own parts, stock and contract systems only means pointing the same four data actions at their tables or views and adjusting the decision rules.
- 0 Custom Services to Run: The Python lookup and pricing services from the first design are gone. Nothing outside the CAI process needs hosting or patching.
- 4 Outcomes From Every Request: Each request ends as Approved, Approved with charge, Refer to another depot, or Part not found, each with the detail needed next.
- 1 Process Holds the Whole Flow: Lookups, rules and the response live in one visible process, with a run history in the console for every request.
- 401 Returned to Unauthenticated Requests: Requests without valid credentials are rejected, so stock and pricing are never exposed.
- 5 Test Requests Checked: Covered, chargeable, no stock, unknown part, and no credentials were each checked with a real request against the published endpoint, and the covered case was confirmed end to end with a 200 OK.
Team
The Big Data Engineers Behind This Project
Our Big Data engineers stay involved from design to ongoing support, ensuring your data solutions are in expert hands.
READY TO BUILD YOURS?
Stop Making Field Engineers Wait for a Stock Check
Tell us how release requests are answered today. The team that built this will show you how one call can check the part, depot stock, and contract, and return the bin or charge on the spot.
