NFR: Secondary Data Holder unable to determine Customer Present

[perlboy]

Description

The Shared Responsibility for Energy section specifies:

The x-fapi-customer-ip-address header MUST NOT be passed to AEMO and AEMO MUST NOT require this header

While the definition of this header states:

The customer's original IP address if the customer is currently logged in to the Data Recipient Software Product. The presence of this header indicates that the API is being called in a customer present context. Not to be included for unauthenticated calls.

Meanwhile the NFRs state that there are different SDH Performance Requirements are variable for certain present vs. not present calls:

Primary Data Holders therefore end up in a situation where Customer Present calls are effectively all Unattended threshold for the SDH. This creates a situation where the primary and secondary data holders do not have aligned expectations resulting in misaligned statistical expectations and consequential reporting characteristics.

Note: I've created this pretty quickly for consideration in this MI and therefore have not had a chance to pass this through Biza.io's Data Standards Committee.

Area Affected

• Shared Responsibility > Energy
• Non-functional Requirements > Performance Requirements

Change Proposed

Introduce an x-cds-customer-present header with a boolean true/false value for all calls to Secondary Data Holders

[johnAEMO]

Feedback from AEMO and reflections on recent conversations during the previous maintenance iteration call:

• AEMO's interpretation of the NFR times (as we are not aware of the customer's presence or otherwise) is to assume that the customer is present unless there are more than one Service Point/NMI requested in which case we have deemed this to be a "Large Secondary Request". This translates to AEMO measuring getServicePointDetail and getDERforServicePoint at 1.5sec NFR with getServicePoints at 1.5secs unless the request is for 2 or more Service Points in which case it would be 4.5secs.
• We note that, for ease of coding, some retailers pipe all DER requests to the same API (getDERforSepcificServicePoints) which attracts a different NFR time (4.5secs) than if they pushed all single Service Point DER requests to getDERforServicePoint (1.5secs) and only multiple Service Point requests to getDERforSepcificServicePoints. A customer present flag would not impact on how this might be reported by AEMO.
• While both of the above practices might not align with how retailers measure their compliance to NFR times, only retailers report their compliance and AEMO does not formally report against NFR times - so how we measure compliance to NFRs is largely for internal and collaborative purposes only.
• AEMO is also concerned that introduction of a customer present flag and/or directing single DER requests to getDERforServicePoint would only achieve alignment of AEMO's internal NFR figures with the retailers' NFR figures while creating additional costs for all parties.
• AEMO would be happy to note on any internal or collaborative compliance reports that these figures are expected to differ from those measured by retailers.

[nils-work]

Hi @perlboy

Re: your proposal for the inclusion of the x-cds-customer-present header (although there was a suggestion it may not be required for Energy), I've noted that FAPI 2.0 Implementation Advice suggests what could be an equivalent - x-fapi-end-user-present.

While this topic has been discussed before do you feel there would still be a preference to align to FAPI headers or to develop CDS headers for CDR requirements?

This could include where a correlation ID may be helpful for endpoints that don't currently have x-fapi-interaction-id specified, such as Get Metrics.