10.3 SP4 resolved issues

This section lists significant issues that have been addressed in IEE 10.3 SP4.

Aggregation

3802460: (SR# 01644617) Aggregation job was not running through the Data Driven Schedule on IEE 10.3 SP3

Resolution: The logic was skipped when the Data Driven Schedule task enhancement was implemented. To resolve this issue, the Data Driven Schedule task enhancement logic was implemented.

AMI Billing Export (ABE)

3525176: (SR# 01510068) ABE task was failing with the error: unexpected exception occurred cannot release application lock

Resolution: The occurred because the procedure "hvbeentity_purge" can enter the CATCH block after the lock has already been released in the main loop, but before the next lock acquisition. In this case, @ABELockRet is not always set to 0 immediately after releasing the lock, so if an error occurs after the release, the CATCH block will try to release the lock again, causing the error "Cannot release application lock." To resolve this issue, the procedure was modified to release the application lock only if it exists.

AMI Data Export (ADE)

3243278: (SR# NA) Graphing reads and ADE export was not working correctly when the daily (1440 minutes) interval length was selected

Resolution: This occurred because while snapping the day forward, IEE was considering one extra day, so the user saw the wrong value while plotting the graph. This issue was resolved by fetching the reading for 1440 (minutes) interval length, while avoiding snapping forward and backward, and fetching only the requested time data.

Configuration

3348367: (SR# 01420788) IEE 10.x task runners and services spawned excessive database connections

Resolution: IEE was not closing the connections while loading entity collections, so these connections are left orphans and not used as pooled connections. To resolve this issue, the code was changed so the connections would close.

3582029: (SR# 01533742) The Configuration Import task was stuck in a running status for an undefined number of hours, fetching all entities and links

Resolution: This occurred because the customer was using a custom SAP adapter to send program-based configuration (PCB) payloads. Other customers have used a similar customization in SAP to do this. But this customer has an issue with certain premise payloads; when premise does not exist in SAP, it still sends payloads with an empty premise tag, which causes long running fetches as it will call Premise_get with no parameters, meaning the payload fetches every premise in the system.

To resolve this issue, logic was added to check if the PBC update element has an empty string as the ID. In this case we cannot process it as we need a valid ID to properly fetch or create an entity. This check is done before any database fetching so the task will fail without executing a long-running fetch.

Platform

2783610: (SR#: 01141839) The Web Service responses were vulnerable to Clickjacking attacks

Resolution: There were no custom headers for internal and public service host services. To resolve this issue, custom headers, X-Frame-Options, Cache-control, and X-Content-Type, for internal and public service host services have been added.

Time of Use (TOU)

3609860: (SR# NA) Customer noticed that the same date was re-aggregated for a channel using the @REGTOU formula

Resolution: During the aggregation of register channel readings for a single day, the process fetches the last good read using the stored procedure StaleReads_Get. On analysis, it was found that StaleReads_Get was fetching the current day’s reading instead of the prior day’s reading. This caused the aggregation logic to use an incorrect value, leading to a shift in results. To resolve this issue, the StaleReads_Get procedure was updated to return the correct result for prior read in both SQL and Oracle.

Validation Estimation (VE)

3672011: (SR# 01578092) Demand Tolerance Consecutive Rule did not skip zeros so any comparison between a zero read and a non-zero read causing false-positive results

Resolution: To resolve this issue, the validation rule was updated so whenever a zero read (or a read close to zero <= 0.000001) is encountered, the rule now skips that read for comparison. It will keep track of the read before the zero value and will later compare it to the next non-zero read.