.
> Telebib2-XML - Business APIs
SYNTAX DEPENDENT COMPONENTS
Introduction - APIs Development status overview  
21/06/2021 : It is what it is : the material as published is in a somewhat "béta" status.
In collaboration with the development team of the sectoral operator, we are setting up these informative pages.
Things as of today
(09.01.2023 - About the Pull versus the Push strategies...)
One could easely get confused about who is the sender and who is the recipient of something...
In general, there is a consensus to see things as follows.
 

PULL : the receiver requests (some data) in/towards some API / that API is made available by the sender / that sender responds with what has been requested...
- request = give me something
- response = that something

PUSH : the sender does send (some data) in/towards some API / that API is made abailable by the recipient / that recipient confirms the good reception of what has been send...
- request = I give you something
- response = OK, I got that...
(04.10.2022 - JavaScript, and hence JSON too, does impose some syntax-rules...)
  • JavaScript Identifiers / Names
    Identifiers are JavaScript names.
    Identifiers are used to name variables and keywords, and functions.
    The rules for legal names are the same in most programming languages.
    A JavaScript name must begin with:
    • A letter (A-Z or a-z)
    • A dollar sign ($)
    • Or an underscore (_)
    • Subsequent characters may be letters, digits, underscores, or dollar signs.
  • Note
    Numbers are not allowed as the first character in names.
    This way JavaScript can easily distinguish identifiers from numbers.
     
  • Note
    The FinDatEx templates, which are documented in the form of Excel workbooks/sheets seem not to adhere to these "rules of thumb"...
    If we consider constructing API's based upon such material, we might have to adapt such things.
     
(09.06.2022 - We are elaborating a "Message Implementation Guide"-alike representation of the JSON content...)
See these first and newer MIGs here.

Do note the following:
  • The material, labelled as the "approach B", is the basis for the functioning of the "EDIMERX" API.
    • There, the idea is to allow the co-existence of actors emitting and receiving and thus handling Edifact messages, with those actors already emitting and receiving XML/JSON messages, or call it XML/JSON structured information.
    So, "EDIMERX" focusses on the "transition".
     
  • The "Business API's" on the other hand, intend to focus on new functionality, not yet facilitated by the existing Edifact-based information exchanges.
    • Note how the "approach B" makes it necessary to stick close to the Edifact way of representing information - as EDIMERX must be capable of the translation in the both directions, especially also back from JSON to edifact.
      This is why in that "approach B" the XML/JSON is still quite "verbose" - it all could be even more simplified and concise.
    • That is why, for these "Business API's" yet another "approach C" is emerging.
    • For the sake of the global coherence, this will make it necessary to add yet another layer of information on/in the Edifact Repository, allowing the "linking" of what is present in the Edifact to such "approach C" names and labels.
      This is something not yet done (21/09/2022) because we are still learning what can/should be done.
 
(21.06.2021 - A first series of so-called Business-APIs have been elaborated...)
The descriptions are to be published here.
 
Business API - Contact Exchange - A first "Application Programming Interface" definition.
The description is published here, in French and in Dutch.
We also do publish a tableview onto this same material.

5/10/2022 - The most recent representation of such material (PolicyholderNewOrUpdate_V2021.00.002) as delivered by our Telebib2 centre.
Note this actually is all about the policyholder's information - and not about what the more generic wording "contact" implies.

For this reason, the Telebib2 centre proposes in addition a more generic "customer - sales-lead" (PartyDescriptionCustomerSalesLead_V2021.00.002) description.
 
Business API - Document Exchange - A second "Application Programming Interface" definition.
The description is published here, in French and in Dutch.
We also do publish a tableview onto this same material.

5/10/2022 - The most recent representation of such material as delivered by our Telebib2 centre, and representing the distinct variants :
Business API - SEPA Direct Debit (enrollment) Exchange - A third "Application Programming Interface" definition.
The description is published here, in French (and in not yet in Dutch).
We also do publish a tableview onto this same material.
Note this is about the SEPA DD (Single European Payment Area - Direct Debit) enrollment phase or action; the agreement in between the Debtor and the Creditor - agreement that will allow for the actual payment collections.
SEPA Direct Debit is a Europe-wide Direct Debit system that allows merchants to collect Euro-denominated payments from accounts in the 34 SEPA countries and associated territories. In these countries all Euro-denominated payments must be collected via the SEPA payment scheme.
The SEPA Direct Debit Scheme operates based upon an instruction from the Debtor (person paying the funds), giving the Creditor (person collecting the funds) authority to collect payments. Debits can be drawn only in accordance with the terms of this mutually agreed instruction.
5/10/2022 - The most recent representation of such material (SEPADirectBankDebit_V2021.00.002) as delivered by our Telebib2 centre.
 
Business API - Funds actualisation - A next "Application Programming Interface" definition.
The description is to be published here...
 
Business API - Premium invoices consultation, returns and backorders - Yet another "Application Programming Interface" definition.
(Updated 21/12/2022)
The description is published here, in French and in Dutch.
We also do publish a tableview onto this same material.

5/10/2022 - The most recent representation of such material as delivered by our Telebib2 centre, and representing the distinct uses :
  • a premium invoice consultation (PremiumNotification_V2021.00.005)
  • a premium invoice return (PremiumNotificationBrb_V2021.00.004)
  • a premium invoice backorder (PremiumNotificationDrq_V2021.00.004)
    (Note how the wording "backorder" tends to some misleading understanding - this is actually about some premium notification, previously returned by the intermediary to the insurer, and now ordered back again by that same intermediary.)