Posting Repaired Data

Make certain the following concepts, as they relate to the repair process flow, are fully understood before proceeding:
  • pending items
  • finalizing an item
  • deferring items
Refer to Figure 1 and the following information for the posting repaired data process.
Figure 1. Posting Repaired Data
chq_izqc_postrepaireddata.jpg
  1. An operator compares the image with the codeline data on the repair page and changes one or more codeline fields to repair an item. This data is sent from the browser to the user interface web application.
  2. The user interface web application sends the repaired data for the item to the Business Rules Server for re-validation. The same context that was used for the original validation is used when the re-validation is performed. If validation cannot occur because the Business Rules Server cannot be reached, an error message is displayed above the image area on the page and error information for error IZQ02001E is written to the system log. This step requires that the following configuration and runtime artifacts be correct:
    • The Business Rules Server must be running and the user interface web application must be able to communicate with it over the network.
    • The configuration of the Business Rules resource adapter must be correct.
  3. The Business Rules Server sends the validation response to the user interface web application.
  4. The user interface web application determines if the repaired data is valid. If the data is valid, the processing continues with step 6. If not valid, the user interface web application returns the re-validation error to the browser page to inform the user and permit the data to be changed and resubmitted.
    Note: A re-validation error is part of a normal business flow and is not part of the troubleshooting discussion.
  5. The item is marked as a pending repair in the REPAIR_INVALID table. The pending repair codes stored in the system disposition column are:
    d
    the item was given a deferred disposition and is pending
    p
    the item has had data changed, has been given a repaired disposition, and is pending
    s
    the item has been given a disposition of unresolved and is pending
    Note:
    1. For debugging purposes, it may be helpful to confirm that the pending status codes are written correctly. To view the system disposition values for the payment IDs, either use the DB2® Control Center or write a query using the REPAIR_INVALID table.
    2. The WebSphere® data source with JNDI name jdbc/izqtxsdb provides the database connection used to update the data. If this data source is not working correctly, the pending repair state is not written.
  6. This step occurs only if there was an item in the pending reject (s) or pending repair (p) state. It also occurs when the operator clicks finalize item when an item is in the pending reject (s) or pending repair (p) state.
    A service request message with the type Payment_Repair_Pending is created. The message contains the disposition data for the pending item for an operator. It is placed on a queue to be retrieved and processed by the Payment Repair engine.
    • The disposition message for an item that has been finalized is placed on the queue with the JNDI name jms/izqToRepairEngine. This is the same queue that handles the ingestion messages from the Transaction Server.
      Note: To confirm that these messages are being produced, either use the WebSphere administrative console to stop the Payment Repair engine enterprise application (repaireng_ejb_ear) or stop its listener port. When the engine is stopped, no messages are removed from the queue. Repair a few items so that messages will flow to the queue. View the payload of these messages as XML by using WebSphere MQ Explorer or another queue browser. Ensure that they are Service_Request/Payment_Repair_Pending messages.
    • The Payment_Repair_Pending messages, which are posted when items are finalized, are placed on the response queue that is specified in the Transaction Server scheduler.xml configuration for the PRESENTMENT_HAS_VALIDATION_ERRORS message. The scheduler XML has the response queue name stored in the jmsReplyQueue parameter.
    • If the queue cannot be posted, it may be because the queue manager was not started, there was an authentication problem, or there was a network problem. If a problem occurred, an error message is displayed above the image area on the page and error messages are written to the system log.
  7. This step occurs only if step 6 occurred and only for items pending in the same states. After posting the message to the queue, the state of the pending item is changed in the REPAIR_INVALID table. The finalizing state codes stored in the system disposition column are:
    q
    a repaired item has had data posted for final processing, but the response indicating that the FTM database has been updated has not yet been received.
    t
    an item with a disposition of unresolved has been posted for final processing, but the response indicating that the FTM database has been updated has not yet been received.
    • For debugging purposes, it may be helpful to confirm that the finalizing status codes are written correctly. To view the system disposition values for the payment IDs, either use the DB2 Control Center or write a query using the REPAIR_INVALID table.
      Note: The finalizing status codes are temporary and are overwritten with final status codes as soon as the repair engine confirms that the FTM database has been updated.
    • Since the repair engine does not process finalizing items until the posted WebSphere MQ messages are received, items will have disposition codes of finalizing repair (q) and finalizing reject (t) until the messages are handled. Upon seeing multiple finalizing disposition codes, perform the following:
      • Verify that the engine and its listener are started.
      • Verify that no WebSphere MQ messages have accumulated in the jms/izqToRepairEngine queue. If the engine and listener are running and there are still messages on the queue, there is likely a problem with WebSphere MQ.
      • If there are no accumulated messages and there are multiple items with pending dispositions still in the database, Transaction Server may have had a problem storing the Payment Repair data or disposition. Check the Transaction Server logs.
    • The WebSphere data source with JNDI name jdbc/izqtxsdb provides the database connection used to update the data. If this data source is not working correctly, the pending repair state is not written and an error message is displayed above the image area on the page.
  8. This step occurs only if there was an item in the pending defer (d) state before step 5, or when the operator clicks the Finalize Item button when there is an item in the pending defer (d) state. After step 5, items that are in the pending defer (d) state are finalized differently than items in the pending repair (p) and pending reject (s) states. They are immediately changed to the deferred (D) state and may be repaired by operators using the deferred item repair page.
  9. The Payment Repair engine receives the messages that were posted to the queue during step 6. There are multiple message types delivered to the engine on this queue, so the engine determines the message type and handles it appropriately. The repair engine application and its listener port must both be running for messages to be received. At this point, Payment_Repair_Pending message processing is not coupled to any activity on the repair page and the user interface application does not need to be running. Errors that occur during processing are written to the system log and not to the user interface.
  10. Messages delivered from step 6 require that data be changed in the FTM database. After reading a Payment Repair pending message, the engine posts a queue with a service request message of type requestUpdate. The queue that is posted is the queue named in the original PRESENTMENT_HAS_VALIDATION_ERRORS message that started ingestion.
    Note: To confirm that the requestUpdate messages are being produced, use the WebSphere administrative console to stop the Payment Repair engine enterprise application, repaireng_ejb_ear. Repair a few items so that Payment_Repair_Pending messages will flow to the queue. Stop the Transaction Server and restart the Payment Repair engine. The engine produces requestUpdate messages that accumulate on the queue on which the Transaction Server is listening.
  11. The Transaction Server receives the requestUpdate message from the queue. The Transaction Server listener profile configuration contains the name of the queue on which the messages arrive.
  12. The Transaction Server changes the data in the FTM database.
  13. The Transaction Server responds to the request for data update with a Service_Response message of type applyUpdates, which indicates that the data has been updated.
    Note:
    1. The message is posted to the queue on which the repair engine listener port listens. Transaction Server responds to the queue name that was specified in the request message.
    2. By stopping the engine and starting the Transaction Server when there are Service_Request/requestUpdate messages queued, the Transaction Server consumes the requests and post responses. With the engine stopped, the applyUpdate responses can be seen on the queue on which the repair engine listens.
  14. The engine receives the applyUpdate response message that confirms that data has been changed.
  15. The engine changes the state of the item in the REPAIR_INVALID table to a final state to indicate that update processing has completed. The final state codes stored in the system disposition column are:
    R
    a repaired item has had its data updated in the FTM database. This is a final state for the item and no further repair activity will take place for the item.
    U
    an item has been marked as rejected in the FTM database. This is a final state for the item and no further repair activity will take place for the item.
  16. This step occurs after all items in a repair unit of work have a final disposition of repaired (R) or rejected (U). When a repair unit of work is complete, the engine sends a Service_Request message of type SET_PRESENTMENT_STATE to the Transaction Server. This request causes the Transaction Server to set the batch state to REPAIRED, which indicates that all repairable items in the batch have a final disposition.
  17. The Transaction Server receives the request from the queue.
  18. Transaction Server sets the batch state to REPAIRED.
  19. The Transaction Server sends a Service_Response message of type SET_PRESENTMENT_STATE, indicating that the request is complete.
  20. The engine receives the response that confirms that the FTM database has been updated. This indicates that the repair unit of work is complete.
  22. The engine sends a Service_Response message of type PRESENTMENT_HAS_VALIDATION ERRORS, which is a response to the initial ingestion service request that caused the creation of the repair unit of work.
  23. The Transaction Server receives the Service_Response from the queue.
  24. The Transaction Server marks the corresponding work in progress record complete.