Source-derived document; reported behaviour, inference and evidence gaps are identified in the text.

08. Integration Catalogue

Diagram coverage

Integration boundary and participants

The application exchanges information primarily among a desktop user interface, the D4_Main controller and its modules, the stores7 database, and report-output destinations. The Java target identifies com.ais.demo.D4_Main as the executable entry point; D4_Main.run() obtains the stores7 database through _app.getDB("stores7") and exposes Customer, Orders, Stock, Reports, and Exit commands. The corresponding Informix-4GL source also declares stores7 and routes the same menu areas to customer, order, stock, and report routines. These are parallel source representations of the same business area, but the evidence does not prove that every Java class is semantically equivalent to every displayed 4GL routine. E0001 E0007 E0010

The principal human participant is a desktop operator who supplies customer criteria, order headers, line items, report selections, and output preferences through menu-driven forms. The operator receives screen messages, browse results, invoices, and reports. The application also accepts special keyboard commands: field help and state selection are documented in the 4GL forms, while the Java target exposes a bang() path that passes entered text to _app.execute(true, Str.valueOf(cmd)). The latter is a command-execution interface, not a normal business-data exchange; its security implications belong in C09. E0007 E0012

User-interface exchanges

Customer entry exchanges values between form fields and the customer record. The evidenced fields are customer_num, fname, lname, company, address1, address2, city, state, zipcode, and phone. The 4GL forms map these fields to the customer table, while Customer.java models the same names with typed Char and integer fields. custform.per applies UPSHIFT to the state field and the telephone picture mask ###-###-#### XXXXX; the generated Java form exposes corresponding customer controls. Field definitions and lengths are detailed in C06. E0007 E0009

Customer search uses query-by-example rather than a single fixed key. The operator can enter literals, ranges, lists, relational operators, and ? or * wildcards according to the help text. In the 4GL path, CONSTRUCT BY NAME query_1 ON customer.* collects the criteria, and a subsequent SELECT * FROM customer WHERE ... retrieves matching rows. In the Java path, query_customer() constructs a predicate, orders results by lname, and provides Next, Previous, First, Last, Select, and Quit browse commands. The evidence therefore supports both the query language and the browse exchange, but the parser and escaping behavior of Construct are not supplied. E0005 E0007 E0009 E0012

State lookup is a related UI-to-data exchange. When the state code is invalid or missing, the 4GL statehelp() routine opens state_list, displays state code/name rows, accepts a selection, and returns the selected code to p_customer.state. state_list.per defines seven visible rows mapped to state.code and state.sname; the Java State_List artifact provides a corresponding state-selection form. The callback wiring and exact Java runtime behavior remain unresolved, although the source-level exchange is clear. E0007 E0009

Order entry receives a customer selection, order header values, and an array of line items. Header values include order date, purchase-order number, and shipping instructions; the forms also represent shipping, backlog, and payment-related fields. A line contains item number, stock number, manufacturer code, description, quantity, unit price, and total price. The order-entry help allows up to ten items, and D4_Globals.java allocates p_items with capacity ten. Stock selection can be invoked while entering stock number or manufacturer code, after which the application retrieves description and unit price and calculates quantity * unit_price. E0007 E0009 E0013

Two order-form variants must remain distinct. order.per and Order.java describe a form with repeated line-entry fields, whereas orderform.per and Orderform.java describe a form using a grid/table structure, including the same broad line-item columns and a form-only running total. The evidence supports these as separate artifacts or variants; it does not establish which one is used in every runtime path. E0006 E0009

Database exchange

The main persistence exchange is between application code and Informix through stores7. The Java runtime configuration names the Informix JDBC driver com.informix.jdbc.IfxDriver, and D4_Main uses the application database handle. SQL is evidenced against tables including customer, orders, items, stock, manufact, and state. Generated records such as P_Orders, P_Items, P_Stock, Customer, State, and X_Invoice provide Java-side representations, but they do not by themselves prove a complete live schema. E0007 E0013

The supplied configurations disagree on connection details. demo/bin/default.properties specifies a JDBC URL for localhost:9088, database stores7, server informix, user informix, and password [credential redacted]. demo/source/demo.properties instead specifies host [internal hostname redacted], port 1526, server ol_informix, and password [credential redacted]. These may belong to different project and runtime contexts, but precedence and actual environment use are unresolved. The values are configuration evidence, not proof of deployment; operational prerequisites and build/run procedures belong in C10. E0007 E0008 E0014

Customer creation sends a complete customer record to the database and receives a generated identifier through SQLCA.SQLERRD[2] in the 4GL source or the corresponding serial-retrieval path in D4_Cust.java. Customer update sends changed fields with a WHERE customer_num = ? condition in the Java target. Deletion first checks related orders and requires confirmation. The Java deletion query counts all matching orders rows while displaying a message referring to “active orders”; whether completed orders should also block deletion is unresolved. E0002 E0007 E0009

Order insertion is the clearest transactional exchange. The application begins a transaction, inserts the order header, obtains the generated order number, inserts item rows, and commits only after the required operations succeed. Explicit rollback is present for reported order or item insertion failures. The 4GL source and help material describe the same BEGIN WORK, ROLLBACK WORK, and COMMIT WORK sequence. However, the Java exception handler does not visibly invoke rollback after every possible exception, and framework status semantics are unavailable; the complete rollback guarantee is therefore unresolved. E0007 E0012

Order update and deletion must not be catalogued as successful exchanges in the Java D4_Orders path: both methods display "This option has not been implemented". D4_Stock similarly exposes add, find, update, and delete methods that only report the same error. The 4GL ordmenu.4gl.main is materially different: it contains Modify and Delete flows, including item replacement and deletion. These conflicting implementations must remain attributed to their exact artifacts rather than being merged into one capability claim. E0002 E0007 E0012

Report and file exchanges

Implemented Java report paths include D4_Report.print_labels() and D4_Report.print_ar(). They accept a print_option of "f" for file, "p" for printer, or "s" for screen. Mailing labels query selected customers and output names, company, addresses, city, state, and ZIP code. Accounts receivable joins customers, orders, and items, selecting orders whose paid_date is NULL, and emits grouped customer and order totals. The report framework’s exact buffering and completion behavior is not present. E0002 E0007 E0012

Backlog and stock-list report methods exist as menu entries and API surfaces but are explicitly stubbed in D4_Report.java; the help source also identifies those options as not implemented. They therefore represent declared interfaces without successful report exchanges evidenced in the Java target. The 4GL report source agrees that print_backlog() and print_stock() display an unimplemented-option error. E0002 E0007 E0012

The repository also contains pipe-delimited unload files such as customer.unl, orders.unl, stock.unl, items.unl, manufact.unl, and state.unl. These are data-transfer or sample-data artifacts rather than demonstrated runtime interfaces. For example, stock.unl uses numeric stock number first, followed by manufacturer code, description, price, unit, and unit description; the manufacturer codes are not the first field. E0009 E0010

Errors, aborts, and unresolved exchange behavior

The application reports validation and persistence failures through _wm.error, ErrorHandler, 4GL ERROR, and status values such as SQLCA.sqlcode. Data entry can be interrupted with keys including DEL, CTRL-C, F2, CTRL-Y, or ESC depending on the artifact. Interrupted customer updates reload the stored row in the Java target; interrupted order entry is intended to avoid committing incomplete data. Exact key mapping and framework handling differ between the 4GL documentation and Java forms, so they should not be treated as identical. E0003 E0007 E0012

Several exchange behaviors remain consequential questions. The Java report predicates concatenate Construct.getQuery() output into SQL, although the escaping contract is unavailable. The 4GL report routines reset int_flag before testing it after a loop, suggesting that an interrupted report may not reach its abort message; this is a source-level analysis claim, not a proven runtime result. The exact report lifecycle, database constraints, exception rollback, and form-file compatibility require further evidence or execution. E0008 E0012

Field names, lengths, record relationships, and representation differences are covered in C06. Runtime prerequisites, connection selection, output destinations, and build or launch procedures are covered in C10.

Expandable topic detail

Browse all topic detail.

Integration data flow

Browse diagrams and evidence gaps.