2. System validates data entry business rules and runs non-DMR BGP according to transaction processing requirements System applies data entry business rules to the saved date to determine whether the data can be saved and runs any non-DMR BGPs. If the business rules pass, processing continues at Step 3. If not, processing continues at Step 2A. N/A N/A 2A. Issue error message System has determined that at least one data entry or BGP business rule has been violated and writes an error message. Processing continues at Step 3. N/A N/A 3. Needs EDS? System determines if the EDT transaction requires EDS Processing. If yes, processing continues at Step 3A. If not, processing continues at Step 4. N/A N/A 3A. Run EDS If EDS is needed, the system calls EDS before going to asynchronous processing. Processing continues at Step 3B. N/A N/A 3B. EDS Success? ICIS determines if EDS was successful. If EDS is successful, processing continues at Step 3C. If EDS is not successful processing continues at Step 3A. If it is successful, processing continues at Step 3C. N/A N/A 3C. Issue error message System has determined that at least one data entry or BGP business rule has been violated and writes an error message. Processing continues at Step 4. N/A N/A 4. Any errors issued? ICIS determines if any errors have been issued for the transaction. If yes, processing continues at Step 4A. If no, processing continues at Step 5. N/A N/A 4A. System does not save data and writes error message(s) to the log System does not save the data and writes an error message to the log. Transaction ends. N/A N/A
1A. Identify all limit sets for the permit with at least one DMR Event – generate a message for each The system breaks the permit transaction down into limit sets. The system then generates a message for each limit set to send to asynchronous processing, eliminating any limit sets that do not have at least one DMR Event (icis_dmr_event), as those limit sets can’t have DMR Form Values and thus do not need to be processed. N/A N/A 2. Message to Async A calling program calls asynchronous processing, sending a message with transaction type and ID of the source record (e.g., Permit, Limit Set, Limit, DMR). Processing continues at Step 3. N/A N/A 3. Async Transaction Message Queue Gets call from calling program and enters in transaction Processing continues at Step 4. N/A N/A 4. Has any DMR Form Values? System checks to see if there is at least one DMR Form Value record for the item being evaluated. If yes, processing continues at Step 5. Else processing ends. N/A N/A
the pre-asynch processing values. The eff_viol_process_flag indicates whether the value should be processed for Effluent Violations (Y) or whether effluent violations should be skipped (N). Table 3.22. Web Asynchronous DMR Violation Processing Triggers System Function Triggers Post-Save Navigation Screen Pre-Asynch Processing Source Type Code in Make Pending Permit Effective Save & Exit Home Save -> EDS -> Narrative Conditions BGP -> Asynch PRM Y Save & Continue Edit Permit Delete Permit Continue Delete Success Message Save -> deleteReissuanceInProgress -> resetPreviousPermitVersion -> EDS -> Asynch PRM Y Permit – Turn CTS On Save in Manage CTS Edit Permit Save -> -> Narrative Conditions BGP Compliance Schedule BGP-> Asynch PRM (one transaction for each Set on the permit for each on period during the change interval) Y Permit – Turn DMR On Save in Manage DMR NR Edit Permit Save -> -> Asynch PRM (one transaction for each Limit Set on the permit for each on period during the change interval) Y Save & Exit Set List
Edit Limit (Base, PML, EA) Change: Limit Type Limit Value Number Optional Monitoring Flag Qualifier Statistical Base Code Stay Data (Stay Type, Stay Start Date, Stay End Date, Stay Violation Calculation Indicator, Stay Value) Save & Exit List Limits Save -> Asynch LMT (one transaction for each segment in the parameter of the limit record updated) Y Save & Continue Edit Edit Limit (Base, PML, EA) Change Unit Code Save & Exit List Limits Calculating DMRValueInStdUnits -> Save -> Asynch LMT (one transaction for each segment in the parameter of the limit record updated) Y Save & Continue Edit Limit Delete Limit Segment (Base, PML, EA) Confirm Delete Success Screen Save -> EDS -> Asynch LMT (one transaction for each segment in the parameter of the limit record updated) Y Edit Limit Key Save List Limits Save -> EDS -> Asynch LMT (one transaction for each segment in the parameter of the limit record updated) Y
Calculating DMRValueInStdUnits Updates received DMR data value in standard units (icis_dmr_value.dmr_value_standard_units and icis_dmr_value.adjusted_dmr_standard_units) when the DMR value does not have a unit code entered (icis_dmr_value.unit_code) EARNC Enforcement Action (EA) Reportable Noncompliance (RNC) BGP flipSensitiveFlagForEnforcementAction Update sensitive flag on parent EA when FO is saved updatePathwayLinkagesForCaseFilesRelatedToEA Update Air Case File Pathways for Federal and Air DA EAs Table 3.24. EDT Asynchronous DMR Violation Processing Triggers provides details about the EDT submissions that trigger asynchronous DMR Violation processing and how icis_async_transaction is populated for each EDT trigger type. 3.24. EDT Asynchronous DMR Violation Processing Triggers System Function EDT Submission Type Transaction Type(s) Technical Specification for Pre-Async Processing Source Type Code in icis_async_transaction Submit Permit Effective Date for the first time and CTS data is submitted with Status Indicator = Active Basic Permit Change, Replace (like Change) ICIS Batch Permit Basic Information Permit Tech Spec PRM Y General Permit Change, Replace (like Change) Permit – Submit Compliance Tracking Status data Permit Change, Replace (like Change) ICIS Permit Basic Information Permit Tech Spec PRM* (one transaction for each Limit Set on the permit for each on period) Y General Permit Change, Replace (like Change) Permit – Submit DMR Non-Receipt Status data Basic Permit Change, Replace (like Change) ICIS Batch Permit Basic Information Permit Tech Spec PRM* (one transaction for each Limit Set on the permit for each on period) Y General Permit Change, Replace (like Change)
Delete – Limit Segment Level when more than one segment exists for the parameter: Base Limit Permit Modification Limit (PML) Enforcement Action (EAL) Limit Delete, Mass Delete ICIS Limit Tech Spec LMT (one transaction for each segment in the parameter of the record updated) Y Parameter Limit Replace (like Change) Edit Limit Key (update Limit(s) Start and End Date) – Parameter Level Parameter Limit Replace (like Change) ICIS Limit Tech Spec LMT (one transaction for each segment in the parameter of the limit record updated) Y Submit Enforcement Action with Final Order data: Submit new NPDES Closed Date Delete existing Closed Date Change existing NPDES Closed Date Formal Enforcement Action Change, Replace (like Change) ICIS Formal Enforcement Action Tech Spec LTS (one transaction for each LS updated) Y Submit Enforcement Action Milestone with NPDES Closed Date (which gets copied to Final Order Closed Date) Enforcement Action Milestone Replace (like New and like Change) ICIS Enforcement Action Milestone Tech Spec LTS (one transaction for each LS updated) Y *When submitting data via EDT that will trigger DMR violation processing, the system will evaluate the data submitted to determine how many transactions to process for each trigger. The “Source Type Code in icis_async_transaction” column specifies the number of transactions If the same dates are submitted for CTS and DMR Non-Receipt, only one row will be added to the log, otherwise, one row per trigger will be added to the log. The Asynchronous Messaging Subsystem (AMS) can be in one of two states, Started or Stopped. While in started state, the AMS starts processing the incoming Asynchronous transactions as they arrive. A stop Command Message can be sent from a Cron job before planned interruptions, such as system going into read-only mode for reporting Extraction, Transformation or Loading (ETL). Upon receiving a stop Command Message, the AMS finishes processing the current transaction and stops processing the remaining Submitted (pending) transactions. In Stopped state, the AMS consumes