-
Type: Improvement
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: wd29
-
Fix Version/s: wd30
-
Component/s: None
-
Labels:None
-
Environment:
Ed Cazalet - see also
ENERGYINTEROP-580
-
Resolution:
Comments in { }
With respect to the Transactive Services Payloads
1. EiCreateTender needs a tendereeParty ID to identify the
counterparty to the Tenderee or each Tender.
{ Accepted
}
2. Canceled Tender should return a list of canceledTenderIDs
{ in wd32 cancel tender takes one party ID and an optional counterPartyID., and 1..* TenderIDs.
The responses (ArrayOfResponses) responds with an ID (of which tenderID is substitutable) and a response for each. So there's a value that can be used as a Tender ID for each tenderID submitted.
So this is in wd32., but is NOT MANDATORY if the cancel is successful. The pattern is to return those that have failed (required) and those that succeeded (optional).
ACTION improve documentation on this point.
}
3. Why does EiRequestTender us counterPartyID rather than
tendereeParityID? As you know I still prefer Party and CounterParty for
Tenderor and Tenderee.
{ Accepted in ENERGYINTEROP-580
}
4. Need EIDistributeTender service
{ Included in wd32
}
5. EiCreateTransaction needs multiple transactionIDs if accepting
multiple Tenders.
{ Rejected. For simplicity in 1.0, a single tenderID is used. Note that the mulitplicity can be at any level inside the eiTransaction, which contains an EMIX Base. Allowing multiplicity inside and outside the emix base is too complex for 1.0, and the work would delay 1.0.
I'm splitting this as a deferred post 1.0 in a new issue (FILL IN THE NUMBER) ENERGYINTEROP-
}
6. Why does ReplyTenderPayload carry emixBase when it does not appear
in any other payload?
{ Thanks for catching this earlier. Corrected by wd32.
}
7. EiRequestTransaction also needs multiple transactionIDs.
{ Accepted. has 0..* transactionIDs.
}