Source-derived document; reported behaviour, inference and evidence gaps are identified in the text.
Return to: 4. Journeys and State Machines — topic detail
Order
In this document
Lifecycle: Order
The order lifecycle evidenced by implementation is creation followed by customer-based selection and viewing. The order module includes methods named for update and deletion, and its interface declares those operations, but the retained implementation reports that the update and delete options have not been implemented. A rejected or placeholder operation is not evidence of a successful state transition. E0002
The help file independently describes order update and deletion as currently not implemented. Thus, the strongest supported conclusion is that update and deletion belong to the intended or declared order surface but are not delivered capabilities in the supplied evidence. This conflicts with the broader fleet description that presents them as supported operations. E0003 E0004
The order interface also exposes backlog-related information, but the presence of a backlog field does not establish an implemented order-status workflow. The evidence does not show successful order-status transitions or a completed update operation. E0002 E0003
Lifecycle: Order
The supplied interface evidence includes update_order() and delete_order() declarations in ID4_Orders.java.svn-base. However, help entries 302 and 304 explicitly state that update-order and delete-order are “currently not implemented.” The supported conclusion is therefore that these operations belong to the declared or documented interface, while the supplied help source reports them as unimplemented; a declaration is not evidence of a successful state transition. E0004
The help material documents order insertion examples using transaction constructs, including BEGIN WORK, ROLLBACK WORK, and COMMIT WORK. Those constructs occur in embedded Informix-4GL example material. No Java transaction implementation, database execution path, or runtime wiring is shown, so transactional order insertion is documented or inherited behavior rather than confirmed execution. E0004 E0006
Orderform.java.svn-base declares a form-only field labeled “Running Total including Tax and Shipping Charges.” This proves the intended display field and label, but not calculation logic. Help entry 2003 refers to item_total() and order_total() within Informix-4GL example text; no corresponding executable Java calculation is shown. E0006
The evidence contains database-operation messages including “Unable to complete update of orders table” and “Unable to insert items.” These messages are therefore defined in the supplied documentation/example material, contrary to a finding that no such messages are present. Their use by the running application remains unconfirmed. E0006
Lifecycle: Order
An order is initiated for a selected customer, collects header and line-item data, and enters a transaction. It reaches a committed state only when the order insert and all item inserts succeed; otherwise the transaction is rolled back. A committed order causes invoice generation. Order update and deletion are represented in the menu but do not implement transitions, instead displaying an unavailable-option error. E0007 E0008
Harten documentation of the Informix 4GL and Java source repository, from the retained 17 October 2026 export. The exact upstream revision analysed is not established. Source findings do not establish runtime behaviour or equivalence between the implementations.
Evidence identifiers are retained for traceability. The underlying analysis records are not included in this public edition; credential values are redacted. About this case study.