belgian insurance sector – e-business standards – concepts concepts existing / implementation...

Belgian insurance sector – e-business standards – Concepts Concepts existing / Implementation incomplete and/or unclear

First created 29.09.2003.These ideas are still valid.

View - Evolutive - slide 229/09/2003 M.Bormans

The chain : static and/or rigid view

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

This is the representation of : - a series of databases (the 3 containers), - permitting the storage of, business wise spoken, the same object-types (the 2 lines), - back- and/or front-office sytems function on top of these databases, using those stored objects.



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

These databases evolve (upwards) towards newer store-able object-types : completer / changed / new / ... object-types. The same happens within the back- and front-office systems.



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

Which is a continuous process ...



What did you see ?



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

Look again ... :



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

Was it first this ...



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

... and then this ...



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

... and this ...



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

... following this ...



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

... this ...



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

... and finally this?



That is not what you did see the first time,

there you only saw ... :



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

this...



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

and this!



Why?



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

Look again ... :



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

If you want to be able to do this ...



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

... or this ...


The chain : an evolutive view

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

You need flexibility... :

Here ... : and here :



• Converter :– A1 <--> P1 ( Assurnet/1 positionnal to/from Assurnet/2 positionnal )– P1 <--> E1 ( Assurnet/2 positionnal to/from Assurnet/2 EDI )– A1 <--> E1 ( Assurnet/1 positionnal to/from Assurnet/2 EDI )

• (Amand-)Parser :– reads, deconstructs and interpretes AS/2 EDI messages into segments,– delivers « segment events » = input to ...– but first do your type-conversions, and your code-translations using specific layers– ... and only then input to your systems or application layers

• (Amand-)Generator :– first do your code-translations, and your type-conversions using specific layers– offers « segment methods » = output from our systems– interpretes, constructs, writes segments into AS/2 EDI messages

• Traductor :– dBase-driven converter H1 <--> E1 (Cie-specific-Host to/from As/2 EDI )– (an outdated solution)

Portima did offer a series of tools, and defined some « best practices » :



• NO COMPULSION :– you could not impose your business-partners the usage of either currency

• NO PROHIBITION :– you had the freedom to use either currency when doing business with your partners

• ( At least if I remember the terms used correctly...– but you certainly do grasp what is meant ! )

• The similar is what we need AROUND Telebib/2 :– it is only similar, as the sole « Compulsion » and « Prohibition » acceptable are those

based on TELEBIB/2• full TB/2 implementation for inputs = « Good Practice »• TB/2 Message Implementation Guidelines implemented for outputs only = « Good Practice »

– No Compulsion :• meaning no company or broker can slow-down the further evolution of TB/2

– No Prohibition :• meaning no company or broker should be slowed-down by a slower TB/2

Remember the Euro implementation :



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

You need flexibility... :

Insurers must implement these different layers here ... :

Brokers must do it here :

this will be the « Real TB/2-compliancy »



If you do not; accept the consequences ...

you (WE ALL TOGETHER) can only do ...



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

this...



dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

and this!

which can be called a « rigid evolutionary chain »



Questions ?• What is Telebib/2 ?• What has this to do with X-Link ?• How to give concrete form to this topic ?



What is Telebib/2 ?

• TB/2 is about « metadata », it is a repository• that repository can be used through an Access dBase• TB/2 is about « grammar », it is an EDI implementation• that EDI implementation is no longer positionnal as it was the case within TB/1,

it ’s pre-decessor • TB/2 is definitely not intended to be a static dataset, it is to be seen as a system

open to evolution



What has this to do with X-Link ?

• X-Link is a user-interface, that can be used within a Broker ’s Office, on his work-station(s)

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

Broker ’s Office

X-Link

• When within X-Link, the broker is actually working within that X’s dBase• In addition, he can import from and/or export to his own dBase• The X-Link user-interface must not speak in TB/2 terms,

otherwise it can only handle objects known in TB/2, and this again creates a rigid « evolutionary chain »

• The X-Link user-interface can speak in TB/2 terms where possible, consider this a « nice to have » only



How to give concrete form to this topic ?

• Do not concentrate on Broker ’s packages X, Y or Z

dBase ofcompany X

dBase ofbroker Y

dBase asexchanged

• Create « translation layers », « in » and « out », based on your own metadata and on the TB/2 referential,

• this way you do not create a rigid link within your part of the « evolutionary chain »,• this way you do create a flexible link, which safeguards your « evolutionary independency »

• If X-Link is more than purely a user-interface, then do transpose these same translation-layers there



Material that might help to better understand it all ... (added 15.05.2008)

• https://mail2003.portima.be/exchange/ with ID/pasword : DocGuest / DocGuest : enter the « public folders » :Folder « DocServer » contains the basic AS/2 material. (indicated as Portima...DocServer\)

• C:\Mike\CiesBrokerPortima\Filecorp\Document distribution\TELEBIB2 :TB98_20080515b.mdb : the Relationships-view : which shows how TB2 refers to TB1, using 4 levels (situation as on 07.08.1997) ...

• Portima...DocServer\Services\Traductor :sy_trdc1.doc and Description DB Traducteur.doc : how to convert TB2-messages to/from proprietary formats, using 10 levels (as documented 12.01.1999) ...

• Portima...DocServer\Services\Parser :sy_apag1.doc and PrivateParser.h : read – isolate – act ...

• Portima...DocServer\Services\generator :history.txt : started 27.06.1996 up to 27.06.2001 :xx.11.1998 : change from 4 to 10 levels ...It is interesting to see how such a generator/parser evolves over time, this can be recognised as a « fluid change capability » ...

https://mail2003.portima.be/exchange/



Material that might help to better understand it all ... (continued)

Portima...DocServer\Documentation\package : PK_NLV4_20080515.DOC :• 3.1. : ... beschikken over een set voldoende generieke functies die gegevens in dit unieke opmaakformaat importeren

en exporteren …• 3.2. : ... wordt geen enkele aanname gemaakt in verband met de verwerkingswijze, de gegevens en de

uitvoeringswijze eigen aan elke toepassing …• 4.1. : ... Elke programmeur mag in het gegevensmodel naar eigen goeddunken te werk gaan, op voorwaarde dat de

regels van de gegevensuitwisseling stipt worden nageleefd. …• 4.2.6.2. : ... De gegevensinhoud van het nieuwe antwoordrecord is de werkelijke maximale inhoud (de maatschappij

geeft alle door haar beheerde informatie waarvoor een TELEBIB2 code bestaat in het conceptuele gegevensmodel). Het pakket bewaart de deelverzameling (subset) die dit kan beheren ...

• 5.1.4.2. : ... Het nieuwe antwoordrecord is algemener dan … , en wordt gedefinieerd op basis van het conceptuele gegevensmodel van TELEBIB2. ...

Trasys : conceptual work preparing AS/2 : exists only in print :• everybody doing his proprietary translations when parsing/generating edi-based messages and/or context-exchanges

is a keystone.(They never said one should try to avoid translation-workload by internally implementing the standard...)

belgian insurance sector – e-business standards – concepts concepts existing / implementation...

Documents