B2B transforms

About B2B transforms

B2B transforms only occur between the current and superseded versions. For example, if the current B2B schema is r41 and you are on the superseded B2B schema r38 then transforms are available. If you are on a non-supported version of the B2B schema then no transforms are available and the transaction is delivered in the version it was sent.

AEMO Australian Energy Market Operator applies an XML eXtensible Mark-up Language. transform to change the schema release of user-selected transaction types, including their acknowledgements. Only the transaction types supported in both the currently supported and immediately superseded schema releases are available for selection, since any transaction type available in only one release of an aseXML schema Specification to describe the structure of an aseXML message. is limited to that release.

For help applying schema transforms, see Nominate B2B Transforms.

Versioning of the transaction types and the aseXML A standard for energy transactions in XML. A set of schemas and usage guidelines that define how data should be exchanged under FRC in the gas and electricity industries in Australia. schema are different, although related. Each aseXML release has an unique identifier, being its namespace identifier (for example, xmlns=”urn:aseXML:r25”). The part after the second colon in the namespace identifier is used as an abbreviation of the aseXML schema namespace identifier, since that is the part that changes from one release of aseXML schema to the next. By convention, transaction types use the abbreviation of the aseXML schema identifier when the transaction type definition last changed as the version identifier of that transaction type. This means the two identifiers are related, look the same, and both can be called a “version”. So, the meaning of the abbreviation (such as “r25”) depends upon its context, and it is possible to easily misinterpret the context due to the relationship. Similarly, the word “version” may refer to the transaction type version attribute or to the aseXML namespace identifier abbreviation, depending upon context. Processing XML files (including transforming) requires clear handling of the namespace, so the B2B Transforms menu has the aseXML schema releases as its primary context, and the transaction types are used to partition the transitioning process (if desired).

The ability to transition one B2B Business-to-Business. Generic term used to refer to defined business-to-business interactions between participants; excludes interactions between a participant and market systems such as MSATS. transaction group at a time allows progressive implementation of the changeover from one aseXML schema release to the next supported release in B2B.

Making the transition from receiving in one release of aseXML to another requires reducing activity to zero, to achieve a clean changeover. Doing nothing for an extended time hampers the flow of B2B business between participants, so a time-limit is imposed for the transition. To prevent an excessive backlog of files to catch up, a maximum is set for the count of .zip files held back from processing during the transition before the changeover is either completed or cancelled.

During the transition time, a temporary holding folder in each participant’s B2B folder, called “parkbox”, holds the files sent by other participants. When the transition between aseXML releases completes, the files in the holding folder are copied or transformed into the outbox and deleted after processing.

B2B transaction types and groups

Versioning of the transaction types and the aseXML schema are different, although related. Each aseXML release has a unique namespace identifier, for example:

xmlns=”urn:aseXML:r25”.

The part after the second colon in the namespace identifier is used as an abbreviation of the aseXML schema namespace identifier, since that is the part that changes from one release of aseXML schema to the next. By convention, transaction types use the abbreviation of the aseXML schema identifier when the transaction type definition last changed as the version identifier of that transaction type. This means the two identifiers are related, look the same, and both can be called a “version”. So, the meaning of the abbreviation (such as “r25”) depends upon its context, and it is possible to easily misinterpret the context due to the relationship. Similarly, the word “version” may refer to the transaction type version attribute or to the aseXML namespace identifier abbreviation, depending upon context. Processing XML files (including transforming) requires clear handling of the namespace, so the B2B Transforms menu has the aseXML schema releases as its primary context, and the transaction types are used to partition the transitioning process (if desired).

The ability to transition one B2B transaction group at a time allows progressive implementation of the changeover from one B2B aseXML schema release to the next supported release .

Making the transition from receiving in one release of aseXML to another requires reducing activity to zero, to achieve a clean changeover. Doing nothing for an extended time hampers the flow of B2B business between participants, so a time-limit is imposed for the transition. To prevent an excessive backlog of files to catch up, a maximum is set for the count of .zip files held back from processing during the transition before the changeover is either completed or cancelled.

During the transition time, a temporary holding folder in each participant’s B2B folder, called “parkbox”, holds the files sent by other participants. When the transition between aseXML releases completes, the files in the holding folder are copied or transformed into the outbox and deleted after processing.

B2B schema change process