Minutes ETC meeting, August 25th and 26th2009
Date:Tuesday and Wednesday,August 25th and 26th 2009
Time:09:00 - 18:00and 9:00 - 17:00
Place:Swissgrid, Frick
Participants:Christoph Ruffing, CH, swissgrid,
Kees Sparreboom, NL, CapGemini,
Ove Nesvik, NO, EdiSys,
Attachment:None
0Summary
The main item during the meeting was defining an ebIX BIELibrary for the EMD documents. The BIEs defined, enough for creating a business document for metered data, will be forwarded to the HG (ETSO, EFET and ebIX® Harmonisation Group) for discussion at the next HG meeting, See Appendix E. After the meeting the ebIX®principles for making the UMM2 Business Information Viewseems agreed. Since also the ebIX® principles for making the UMM2 Business Choreography Viewwas agreed during the two previous meetings, the CuS and EMD working groups should now be able to produce a complete UMM2 model.
In addition to the UMM2 modelling, a proposal for a common business document header was made (also to be discussed at the coming HG meeting) and some questions were prepared for the coming UN/CEFACT Forum meeting.
1Approval of agenda
The agenda was approved with a slightly changed sequence of the items.
2Approval of minutes from previous meeting
The minutes from previous meeting were approved.
3Short presentation of principles of an Information Model (from CuS)
Since the focus of the meeting should be the UMM2 Business Information View (CCs) and a standard Header, the presentation was skipped.
4Question from Jon-Egil: Why do we have ebIX/ETSO capacity product codes?
Since Jon-Egil not could participate at the meeting the question was postponed.
5Status for ebIX® profile for MagicDraw, including Core Components, Code lists, Templates, etc.
The question to MagicDraw (NoMagic) related to if a Dependency should be able to use stereotypes with metaclass InformationFlow was postponed because of the summer holidays.
Kees showed his homework for updating the CEFACT profilewith the UN/CEFACT ACCs from CCL 08A. About half of the UN/CEFACT ACCs has been updated with definitions, cardinality, stereotype and sequence of the attributes.The updated ACCs are the ones that most probably may be used by ebIX®. This means that we are now able to create our ebIX® ABIEs based on the CEFACT profile.
A few comments related to the MagicDraw profile for the Harmonised role model were raised:
- At the latest CuS meeting the role Consumer was discussed, related to a contract model, which shows one Partyconnected to the gridwith severalcontracts. And these contracts may be related to different Consumers. How to deal with this problem will be brought up at the next HG meeting.
- A discussion related to if we need to split the Metered Data Aggregator into Metered Data Aggregator, local and Metered Data Aggregator, central will also be brought up at the next HG meeting.
6Continuation on the Business Information View for the CuS and EMD models
The main item during the meeting was defining a new ebIX BIELibrary for the EMD documents. The BIEs (Metered data document) defined will be forwarded to the HG for discussion at the next HG meeting, see Appendix E.
The following rules made during the meeting will be added to the ebIX® Methodology:
- The qualification term of the BIE- and QDT- names should give meaning to the BIE(QDT, e.g. DomainLocation. A qualification text may include Energy, but this is not mandatory unless the BIE is special for the energy market and also may be used in other sectors.
- Candidate ACCs, e.g. TimeSeries, will be stereotyped with <Candidate> in addition to <ACC>.
- Alternative Primitive types for the QDT attributes (content and supplementary elements) are specified in the UN/CEFACT DT-Catalogue. We interpret this as a possibility to restrict primitive type, by more restricted primitives, e.g. the content component of the CDT Measure has the primitive type of Decimal, which was restricted to Integer.
- In the ebIX® profile(BIELibrary) ebIX will make ASCCs and ASBIEs for those associations that will be used for all (or almost all) business documents. These will later on be used to definebusiness documents in the DOCLibrary (in the UMM2 Business Information View). For association only used in some business documents the associations will be made directly in the DOCLibrary (in the UMM2 Business Information View). Ove noted however that this is in conflict with the current UN/CEFACT rules (i.e. UPCC and CCMA). Some consequences:
- This will at least contradict with the CCMA specification.
- The XML schemas for the business documents will have to include relations to those ABIEs not having an ASBIE association in the ebIX® profile.
- The only package used in the UMM2 Business Information View will be the BIELibrary. The other packages specified in UPCC will be found in the ebIX® profile.
7ebIX® header and its relation to SOAP
A proposal for a common document header was requested at the latest ebIX® Forum meeting and expected to be discussed on the next HG meeting, see Appendix E.
From the related discussion:
- The content of the common document header will be dependent on the communication channel, e.g. SMTP or WS.
- The request for acknowledgement was removed from proposal for a common business document header. However, Christoph was a bit worried, because this element is currently important for Switzerland. It was stressed that the rules for sending (not sending) acknowledgements must be stated in the process part of the UMM2 models, i.e. as tagged values connected to the transactions.
- See also Appendix Dfor an overview of the SOAP header.
8Business Choreography View for the CuS and EMD model (if needed/questions)
EMD and CuS will come up with proposals for complete UMM2 models for a few processes, which will be reviewed on the next ETC meeting.
Homework:
- Kees and Ove will make EMD and CuS examples of a complete UMM2 model.
9Status for discussion with Christian Huemer
A mail exchange with Christian Huemer was reviewed/discussed, see Appendix C, and the proposed answer from Kees was agreed.
It was also discussed what to rise at the next UN/CEFACT Forum meeting:
- Request to UPCC for addition of the property Status to the Code list Entry stereotype.
- Propose to use the ebIX® UMM profiles as official MagicDraw profiles
- Follow up the DMR for renaming of the code 260 (Code list responsible) to ebIX®.
- Request detailed transaction patterns (activity diagrams) and description on how to see the difference between them from TMG.
Homework:
Kees will send the proposed mail to Christian.
10Status for UMM part of the ebIX®modelling methodology
During the update of the CCs and UMM2 Business Information View the UMM part of the ebIX® modelling methodology was updated accordingly.
11Status for cooperation with Christian Senf, University of Berlin, related to maintenance of the UMM profile for MagicDraw
The possible cooperation with Christian Senf will be followed up by Ove during the next UN/CEFACT Forum.
12If time items
12.1Status for participation in UN/CEFACT (TBG1, TMG), ETSO/TF-EDI and IEC/TC57/WG16
Postponed
12.2XML schemas based on the Business Information View from the CuS and EMD working groups
Postponed
12.3Integration of the ebIX® model for acknowledgement and error handling into ebIX® models (UMM compliant)
It was a short discussion related to the usage of the ebIX® Processability error report. The ebIX® Processability error report is in use by several countries, but does not fit the UMM2 transaction patterns. It was suggested to skip the ebIX® Processability error report from the new UMM2 models. Instead other solutions should be implemented, such as usage of a two-way pattern (where the ebIX® Processability error report is implemented as a rejection) or creation of a new transaction when error reports are needed. The latter may include the need for a reference to a completed transaction within the new transaction documents (usage of the overall business process id).
13Maintenance of ebIX® Domain model
Postponed
14Next meeting(s)
- November, Wednesday 18th and Thursday 19th, Austria (before the next ebIX® Forum meeting.
15AOB
No items
Appendix AParticipants in ETC
Name / Company / Telephone / Mobile / E-mailAlexander Pisters (vice convenor) / RWE / +49 234 515-2442 / +49 162 257 5428 /
Christian Odgaard / Energinet.dk / +45 76 22 44 63 / +45 23 33 85 55 /
Christoph Ruffing (Coordinator of ETC modelling expert group) / swissgrid / +41 58 580 21 37 / +41 76 313 15 63 /
FilipDrijkoningen / Infrax/ UMIX / +32 11266495 / +32 4 95586471 /
Jan Owe / SvK / +46705 396 930 /
Jon-Egil Nordvik / Statnett / +47 22 52 70 00 / +47 975 36 303 /
Kees Sparreboom / TenneT / +31 622 66 7911 /
Lucy Sarkisian (Convenor) / TenneT / +31613 643 092 /
Ove Nesvik (Secretary) / EdiSys / +47 22 42 13 80 / +47 928 22 908 /
For information:
Adrian Fuchs / swissgrid /
Cynthia Bonne / Eandis/ UMIX /
Rudolf Baumann / swissgrid /
Observers:
Daniele Bui / EDF Distribution /
Heli Anttila / Fingrid /
Juraj Horvat / VSE Kosice /
Lembit Sünt / Estonian Energy /
Radoslav Haluska / VSE Kosice /
Riina Heinimäki / Finish energy /
Svein Olsen / Navita /
Sylvie Mallet / EDF R&D /
Terje Nilsen / Nord Pool / +47 67 52 80 44 / +47 930 34 100 /
Tor Åge Halvorsen / Nord Pool /
Willem Strabbing / KEMA /
Appendix BThe tasks of the General ETC and the ETC Modelling expert group
Task / Group / Priority / PlannedMaintain the ebIX® technical documents:
- ebIX® Modelling Methodology (Draft for v2.0A)
- ebIX® Modelling Methodology (Draft for v2.1A)
- Evaluate if a paragraph related to OO modelling is needed when the first complete ebIX® UMM compliant model is available.
- National customisation using the Business realisation View
- ebIX® common rules and recommendations (v1r1D)
- ebIX® Recommendations for acknowledgement and error handling (v1r0C)
- ebIX® Recommended identification schemes for the European energy industry (v1r1D)
To be done
When need
To be done
When need / Q1 2009
Q2 2009
Maintain ebIX profile for MagicDraw, including:
- Core Components
- Code lists
- Templates, etc.
(after EMD and CuS RSM)
Participation/representation in the ETSO, EFET and ebIX® Harmonisation group
- Maintaining harmonised role model
- Core Components
- Information exchange between participation organisations
Participation in:
- UN/CEFACT
- TBG1
- TMG
- ETSO/TF-EDI
- IEC/TC57/WG16
Input of information for the ebIX® web site / General ETC / Urgent
Organise implementation support, such as:
- ebIX® course
- Implementation support for participating countries, such as inserting/updating codes.
Supporting ebIX® projects, i.e.:
- Develop and maintain the UMM Business Choreography View and Business Information View from the CuS and EMD working groups.
- Develop and maintain XML schemas based on the Business Information View from the CuS and EMD working groups
- Integration of the ebIX® model for acknowledgement and error handling into ebIX® models (UMM compliant)
- Maintain ebIX® Domain model
Maintaining EMD and CuS models when standards of relevance are updated, i.e.:
- UMM
- NDR
- CCL (and CCTS)
- UPCC
- Harmonised European role model
Appendix CMail exchange with TMG (Christian Huemer)
Dear all,
My proposal for the answer to Christian Huemer:
Dear Christian,
Thanks for your response anyway ;-)
- Regarding the patterns: we see that the present list of tag definitions bears no consequence within the UML model whatsoever. It is text. Consequences can only be found outside the UML model in documentation published elsewhere. We would like to enable the UML model to find the consequences within the UML model. But we also prefer, that for the specification of the patterns this will be done within UMM.
- Regarding Information flow versus Dependency: we will in the meantime keep the dependency but we will also ask MagicDraw whether this could be a bug in their software.
- Regarding the roles: re-use across project sounds nice, but will only really work if these projects have predefined roles like requestor/provider made available by for instance the UMM profile. At least the Harmonized Role Model for the energy sector has made this possible for all project within the European energy sector. So the questions rephrased should be: does TMG intend to include this kind of generic modeling roles in UMM?
- Regarding the parameters that define the context for the Realization on top of what has been specified in the Transaction/Collaboration: yes we are aware of the complicated nature. Especially since we realize that the whole concept of re-use by means of realizations will only work, if we have some context-mechanism that will enable the customization of re-usable elements for a particular context. (As by the way is true for the re-use of CC’s as well!! And for proper re-use of CC’s in a UML model there should be more than just naming rules or suggestions to use OCL-statements). So since we both know that context is required for re-use to work, what are we going to do about this? Is this a priority for TMG? Could we be of any help? When do you expect (and could we expect) practical results?
Best regards,
………., ebIX
Could you all agree?
Regards, KSp.
From: Christian Huemer [mailto:
Sent: donderdag 9 juli 2009 19:39
To: Ove Nesvik
Cc: Sparreboom, Kees; Lucy Sarkisian; Christoph Ruffing; Jon-Egil Nordvik; Alexander Pisters; Marco Zapletal
Subject: RE: Questions from ebIX
Hi Ove,
Sorry for the late reply – as usual ;-)
I will be at the Sapporo Forum September 28 – October 2nd. There is not TMG meeting before the Forum. There was a meeting of the TMG Core Components Working Group starting on the day you sent your mail. However, the Business Process Working Group of TMG did not meet, because we could not agree on a date that were appropriate for all members.
Points 1 and 2 need some discussion. There seems to be some misunderstanding on the concept of a pattern. I guess I know what you are trying to achieve … but this is rather a tooling issue, not a meta model issue.
Point 3 sounds reasonable. We will have a look on it.
Point 4: If you do the same business transaction / business collaboration between a different sets of business partners. Example: Business Collaboration A is executed between business partner X and Y or between business partner X and Z. Furthermore it will foster re-use across projects. Business Transaction “Request for Quote” may be reused in different domain, there is always a “requestor” and a “responder”, but it is unlikely that Tourism uses the same Roles as Energy.
Point 5: You are touching a complicate area here ;-)
Best regards,
Christian
From: Ove Nesvik [mailto:
Sent: Monday, June 22, 2009 11:25 AM
To: Christian Huemer
Cc: Sparreboom, Kees; Lucy Sarkisian; Christoph Ruffing; Jon-Egil Nordvik; Alexander Pisters
Subject: Questions from ebIX
Dear Christian,
On our latest ebIX meeting we came up with a new list of questions related to UMM (see below), which we would like to discuss with you (TMG), unless you have some immediate answers. Are there any TMG meetings before the next UN/CEFACT forum where these questions may be discussed?
And, will you participate on the next UN/CEFACT Forum September 28 – October 2nd?
Questions:
- In the Business Transaction View the enumeration Transaction pattern is defined for the 6 different Transactions patterns fromUMM (Notification, Request/confirm,…). ebIX suggest that we instead of referencing this enumeration, reference UMLActivities (templates as activity diagrams) for the 6 different Transactions patterns. The proposal includes creation of the stereotype <TransactionPattern> (with base class Activity) for these UMLActivities (Transaction patterns), to avoid mix-up with normal Business transaction activities. This also means that the enumeration Transaction pattern can be removed.
- If the proposal above is agreed upon, it would be possible to create generic states per transaction pattern, to be used in the Business transactions.
- According to UMM the base class for the stereotype Initiating Flow and Responding Flow is Information flow, represented as a Dependency. According to MagicDraw, an Information flow can be presented as different objects, among others as a Dependency. However it is not possible to link the stereotype Initiating Flow or Responding Flow to a Dependency as long as the base class is Information flow. We therefore had to change the base class for Initiating Flow and Responding Flow to Dependency.
- Within ebIX we have the Harmonised role model, which is the complete set of roles we want to use in our models. What could be the arguments against using the roles from the Harmonised role model instead of creating new Authorised roles for all Business Transaction Views, Business Collaboration Views and Business Realisation Views?
- ebIX sees the need for having “parameters” transferred from the Business Realisation View to the Information Envelops in the Business Transaction View, i.e. the content of the Information Envelop may vary between different Realisations. Isthis a “lacking feature” in UMM?
Have a nice day!
Rgds,
Ove Nesvik
Senior rådgiver / Senior adviser
Mobil (+47) 928 22 908
------
EdiSys Consulting AS
Øvre Slottsgt. 17
NO-0157 OSLO
Telefon (+47) 22 42 13 80
Telefax (+47) 22 42 26 40
Appendix DSOAP Envelope-Document structure
Appendix EebIX ACC-ABIE Proposal 20090826
ETC - ebIX Technical CommitteePage: 1