career database exchanges specifications - nisse | … · web viewif a pow request message does not...

RSVZ - INASTI de 94Career Database Exchanges Specifications Subject: PEN - Career Database

Author Yves Van Dooren

Other authorsVersion 1.3

Date 3/08/2009

CSC Validation RSVZ approval

Date: Signature:

P. Vanderbauwede

CIO

document.doc 1 /94 Date: 3/08/2009

RSVZ - INASTI

PEN - CAREER DATABASE

CAREER DATABASE EXCHANGES SPECIFICATION


Updates History

DATE VERSION BY REASON PAGES03/09/2008 0.1 Yves Van Dooren Creation9/10/2008 0.2 Yves Van Dooren Full review

12/11/2008 0.3 Yves Van Dooren Specific B2B elements withdrawal

26/12/2008 0.4 Yves Van Dooren Begin translation to english11/02/2009 0.5 Yves Van Dooren Complete review 20/02/2009 0.6 Yves Van Dooren Upgraded + Updated with

remarks from SVMB24/02/2009 0.7 Yves Van Dooren Upgraded + B2B changes4/03/2009 0.8 Yves Van Dooren Finalization All20/3/2009 0.9 Yves Van Dooren Updated with remarks from

SIFs22/04/2009 1.0 Yves Van Dooren Incorporates changes from

meeting with SIFs on 22/04/09 and written questions

28/04/2009 1.0.Final Yves Van Dooren Data values reviewed according to defined structures

1/07/2009 1.1 Yves Van Dooren Correction of some discrepancies with the WSDL (RC 1.1.0.5)

3/08/2009 1.2 Draft Yves Van Dooren Integrated remarks from BIS review. 74L layout still to be updated.

14/09/2009 1.2.2 Yves Van Dooren Integrated more remarks from BIS review. 74L layout updated.

12/10/2009 1.2.2 Yves Van Dooren Removed reference to ack. Response data structure.

39

23/10/2009 1.2.2 Yves Van Dooren Application name “CareerDB” replaced by “1202”

17/11/2009 1.2.3 Yves Van Dooren Enhancements to refresh processing description

62, 63

25/01/2010 1.2.3 Yves Van Dooren Inconsistent values for RefreshCareer flow type name

66 and later

10/02/2010 1.2.3 Yves Van Dooren Revision of Career download 70 and later17/05/2010 1.3 Yves Van Dooren Revision of Signal 74L17/05/2010 1.3 Yves Van Dooren Handling duplicate dossiers 38, 507/10/2010 1.3.1 Yves Van Dooren Review of 74L messages

structures82 and later



Table of content

1. Introduction.....................................................................................................................................7

1.1 Objet.......................................................................................................................................7

1.2 Target audience.....................................................................................................................7

2. Career database Use cases..............................................................................................................8

2.1 Career database data exchange Use cases...........................................................................8

2.2 Application monitoring and control Use cases.................................................................11

3. Conceptual Architecture...............................................................................................................12

4. deployment view.............................................................................................................................13

4.1 Applications.........................................................................................................................13

4.2 Protocols...............................................................................................................................134.2.1 Application-level protocols.............................................................................................................134.2.2 Low-level protocols.........................................................................................................................154.2.3 POW issues and general error processing.......................................................................................174.2.4 Bulk load protocol specificities.......................................................................................................18

5. Scenarios.......................................................................................................................................20

5.1 Introduction.........................................................................................................................20

5.2 Summary..............................................................................................................................20

5.3 Manual Initial load..............................................................................................................225.3.1 Process.............................................................................................................................................225.3.2 Validation........................................................................................................................................255.3.3 Data structures.................................................................................................................................255.3.4 Data contents...................................................................................................................................265.3.5 quantitative data..............................................................................................................................28

5.4 Bulk Initial load...................................................................................................................295.4.1 Process.............................................................................................................................................295.4.2 Sequence..........................................................................................................................................295.4.3 Validation........................................................................................................................................295.4.4 Data.................................................................................................................................................29

5.5 Bulk full career data Upload..............................................................................................315.5.1 Process.............................................................................................................................................315.5.2 Flow management...........................................................................................................................355.5.3 State machine on SIF side...............................................................................................................365.5.4 Validations at career db side...........................................................................................................375.5.5 Validations at B2B side...................................................................................................................385.5.6 Validations at SIF side....................................................................................................................395.5.7 Data.................................................................................................................................................39

5.6 Quarterly upload.................................................................................................................495.6.1 Process.............................................................................................................................................495.6.2 Validations at career db side...........................................................................................................495.6.3 Data.................................................................................................................................................50

5.7 Single career upload............................................................................................................585.7.1 Process.............................................................................................................................................585.7.2 Flow management...........................................................................................................................615.7.3 Validations at career db side...........................................................................................................615.7.4 Data.................................................................................................................................................61



5.8 Career Refresh request.......................................................................................................635.8.1 Process.............................................................................................................................................635.8.2 Validations.......................................................................................................................................645.8.3 Data.................................................................................................................................................66

5.9 Career download.................................................................................................................715.9.1 Process.............................................................................................................................................715.9.2 Validations at career db side...........................................................................................................725.9.3 Data.................................................................................................................................................73

5.10 Business Signals...................................................................................................................785.10.1 Process.............................................................................................................................................785.10.2 Sequence..........................................................................................................................................795.10.3 Validation........................................................................................................................................795.10.4 Data.................................................................................................................................................79

6. Influence on other systems and processes....................................................................................88

7. Appendixes.....................................................................................................................................89

7.1 Schemas................................................................................................................................89

7.2 WSDL...................................................................................................................................89

7.3 Formulas and values...........................................................................................................897.3.1 Upload rejection threshold..............................................................................................................897.3.2 Timeouts and Delays.......................................................................................................................89

Notes - Questions....................................................................................................................................91



Table of figures

Figure 1: Career DB use case diagram..........................................................................................................................10Figure 2: Conceptual Architecture..................................................................................................................................12Figure 3: Interactions between applications...................................................................................................................13Figure 4: Bulk transfer application protocol..................................................................................................................14Figure 5: Career data exchanges protocols....................................................................................................................15Figure 6: "Unexpected" business response.....................................................................................................................18Figure 7: Manual transfer and load sequence................................................................................................................24Figure 8: CreateAllCareers general structure................................................................................................................25Figure 9: Career creation report structure.....................................................................................................................26Figure 10: Bulk upload application level sequence diagram..........................................................................................33Figure 11: Bulk transfer sequence details - SIF side......................................................................................................34Figure 12: Bulk upload sequence details - PEN side......................................................................................................35Figure 13: Bulk Upload SIF State Diagram...................................................................................................................36Figure 14: Structure of UploadCareerData element......................................................................................................40Figure 15: SubjectPerson structure................................................................................................................................40Figure 16: Structure of CareerDetail element................................................................................................................41Figure 17: Structure of UploadAcknowledgementData..................................................................................................41Figure 18: Structure of ReportData element...................................................................................................................42Figure 19: Structure of UploadQuarterData element....................................................................................................51Figure 20: Single career upload sequence......................................................................................................................59Figure 21: Detailed single career upload sequence diagram.........................................................................................61Figure 22: Career refresh request data structure...........................................................................................................66Figure 23: Upload on refresh request.............................................................................................................................67Figure 24: Career download sequence diagram.............................................................................................................72Figure 25: RequestCareerData element structure..........................................................................................................73Figure 26: CareerInfo structure......................................................................................................................................74Figure 27: Application level signal notification sequence..............................................................................................79Figure 28: Low level signal notification sequence..........................................................................................................79Figure 29: ChangeData structure...................................................................................................................................81Figure 30: Pension request signal structure...................................................................................................................82Figure 31: 74L signal structure.......................................................................................................................................82Figure 32: 74L response signal structure.........................................................................................................................83

Dictionary of acronyms

SIF Social Insurance Fund (SVF in Dutch, CAS in French)

B2B RSVZ-INASTI gateway platform for “Business to Business” exchanges

RR Request-Reply B2B protocol

POW Pseudo One Way B2B protocol

CDBA Career DataBase Application at RSVZ-INASTI



Reference documents

[REF1] : FDS0510 Base de données carrière indépendants version 0 5 dd 18 07 2008[REF2] : RSVZ - B2B Guidelines – V2.docx[REF3] : SAD 1.5 RSVZ – Fluxen.docx version 32



1. INTRODUCTION

1.1 OBJET

This document is intended at providing the detailed specifications of the data exchange concepts defined in [REF1] taking into account the rules defined in [REF2] and [REF3], i.e. to define the data exchanges scenarios as well as data exchanged by the business processes of both SIFs and the Pension application of RSVZ-INASTI.

The details of technology, application, organization and localization are specific to each implementation and will be the subject to separate specifications.

The aspects specific to transport through the B2B interface are described in [REF2].

1.2 TARGET AUDIENCE

This document combines technical as well as functional aspects and is therefore targeted to a large audience of both RSVZ-INASTI and the social insurance funds:

Technical management

Architects and technical analysts

Functional analysts

Application managers

Programmers



2. CAREER DATABASE USE CASES

2.1 CAREER DATABASE DATA EXCHANGE USE CASES

The following data exchanges between a SIF and the RSVZ-INASTI PEN application are expected:

- Initial Loado Transfer in one logical shot split into one or more physical transmissions of all

career data managed by the SIF to the PEN career database. Career data that is not electronically available at the SIF at the time of initial load must be transmitted later to RSVZ by means of updates.

o Implementations: Manual: transmission by the SIF of related data by means of a hardware

support and loading of the data by a specific ETL program at RSVZ. Automated: use of the B2B platform to transfer grouped data from the SIF

to the PEN application by means of XML web service messages.o Triggers:

Manual intervention at SIF side.

- Single career uploado Spontaneous transfer of the full career and unconditional pension rights of a given

person by the SIF to the PEN career database. o Implementation:

Automated: use of the B2B platform to transfer the data from the SIF to the PEN application by means of XML web service messages.

o Triggers (specific to SIF): Change in known data Data made available electronically Refresh requested by career DB application

- Multiple careers uploado Spontaneous transfer of the full career and unconditional pension rights of a group

of persons by the SIF to the PEN career database. o Implementation:

Automated: use of the B2B platform to transfer the grouped data from the SIF to the PEN application by means of XML web service messages.

o Triggers (specific to SIF): Data made available electronically Massive updates …

- Single career refresho transfer by the SIF of the full career and unconditional pension rights of a person

upon solicitation by the PEN application. o Implementation:

Automated: use of the B2B platform to solicit and transfer the data between the SIF to the PEN application by means of XML web service messages.

o Triggers (specific to PEN): Need of pension computation Need of pension estimation Error during previous upload …



- Quarterly careers uploado Spontaneous transfer by the SIF of career data of the just expired quarter of all

affiliated persons for whom an update is required to the PEN career database. o Implementation:

Automated: use of the B2B platform to transfer the grouped data from the SIF to the PEN application by means of XML web service messages.

o Triggers (specific to SIF): Quarter expiration

- Single career downloado Transfer of the full career, unconditional pension rights and change history

extracted from the data stored within the central career database for a given person and an affiliation period to the SIF.

o Implementation: Automated: use of the B2B platform to request and provide the data by

means of XML web service messages.o Triggers (specific to SIF):

Single update to career data

- 74L signalo Sending of “74L” notification messages from PEN to SIF and optionally in

response from SIF to PEN. o Implementation:

Automated: use of the B2B platform to notify the signals by means of XML web service messages.

o Triggers (specific to PEN): After pension computation, under particular circumstances depending on

the person current situation.

- Other business signalso Sending of business signal messages from PEN to SIF. o Implementation:

Automated: use of the B2B platform to notify the signals by means of XML web service messages.

o Triggers: Need to compute pension Need to estimate pension



Figure 1: Career DB use case diagram



2.2 APPLICATION MONITORING AND CONTROL USE CASESBesides the data transfer uses cases, the career database application will have to implement monitoring use cases in order to allow recovering from abnormal situations especially for bulk transfers that could span long periods of time (normally a few minutes or a few hours in some exceptional cases).The SIF and B2B systems will equally also have to be monitored and provide control use cases in order to facilitate error recovery.Monitoring requirements are highlighted in this document but their implementation is specific to each party and therefore not described within this document.



3. CONCEPTUAL ARCHITECTURE

Figure 2: Conceptual Architecture


RSVZ - INASTI

SIF 2

SIF n

SIF 1

Pension Database

Subject person

Initial load

Browse personal data

(2010)

Refresh requests,Signals, 74L

Quarters, Career Refreshes, Enquiries

Estimation as of the age of 55

-WS-

-WS-

ONP – RVP, …

InformationExchanges

Flows described within the present documentFlows linked to the career database


4. DEPLOYMENT VIEW

4.1 APPLICATIONS

Figure 3: Interactions between applications

4.2 PROTOCOLSThe SIF is directly connected to the B2B gateway which does not preclude that the SIF application communicates with the Career DB application and that at application level both parties do not see the B2B gateway as a participating party. However at lower levels, the B2B gateway has direct influence on the protocol. The current specification provides

o definitions of application level protocolso directions on how to use the B2B protocols to support the application protocolo indications about influence that B2B protocols can have on application behaviour.

4.2.1 APPLICATION-LEVEL PROTOCOLSThe career database data exchanges will involve the use of three kinds of application protocols depending on the use case:

- Bulk transfer career db protocol- Interactive protocol- Mixed pseudo-one-way exchange protocol

4.2.1.1 Bulk transfer career db protocol


SIF RSVZ - INASTI

PEN application

B2B

SIF Database

Central Career Database

SOAP/HTTPSWS-*

SOAP/HTTPWS-*

Initial load


Bulk transfer protocols allow the sender to transfer a large amount of data to the receiver by sending a flow of pseudo-one-way (POW) messages containing the business payload to the receiving part before receiving first a global transfer acknowledgement and then a processing report.

Figure 4: Bulk transfer application protocol

The bulk transfer career DB protocol uses the bulk transfer features offered by the B2B infrastructure (mainly the Block numbering feature and the “Flux” definition) and is used for the following use cases (all initiated by the SIF):

- Quarterly Upload- Automated Initial Load- Bulk career updates upload

4.2.1.2 Interactive protocolInteractive protocols use the synchronous Request-Reply pattern to get information from the receiver. This protocol is used by the SIF to online retrieve the career data stored within the career DB for a given person.No “Flux” is used by this protocol.

4.2.1.3 Mixed pseudo-one-way exchange protocolThis last class of application protocol involves sending POW messages from one end to the other following a half-duplex flip-flop pattern1. Both parties build a kind of conversation where each one is allowed to speak after receiving the message from its peer. It is used in the following scenarios:

- Signals- Single updates- Refresh requests

Single updates and refresh requests use the “Flux” feature.

1 Half-Duplex: The application dialogue does not allow both parties to send messages concurrently Flip-Flop: the sender switches to receiving mode after sending a message, the receiver switches to sender after receiving a message.



4.2.2 LOW-LEVEL PROTOCOLSExcept for an optional manual initial loading, the data exchanged between the SIFs and the RSVZ-INASTI will be transmitted through the B2B platform of the INASTI. This thus forces using the protocols and rules described in [REF2] and [REF3], i.e. using HTTP/SOAP web service invocations.The following protocol stack results from these specifications.

Figure 5: Career data exchanges protocols

The following options have been pictured as part of the protocol but rejected after further discussions with all involved parties. These are:

- WS-ReliableMessaging, that allows the dialoguing applications to rely on this transport layer to manage repetitions, duplicates handling and message ordering. Issues like interoperability, availability of protocol stack, persistence, loss of ordering at SIF and B2B levels, error notifications and recovery led to abandon this feature.


SIFApplication

TCP/IP

Routing

CAS-SVF B2B PEN application

ApplHeader

Career DB Protocols

INASTI

Levels described in this document

Levels described in [REF2]

TCP/IP TCP/IP

SSL

HTTP

TCP/IP

SSL

HTTP HTTP

SOAP 1.1 SOAP 1.1 SOAP 1.1

B2B spec B2B spec B2B specApplHeader

PENApplication

HTTP

SOAP 1.1

B2B spec

Compression Compression Compression Compression


- Message data compression, interesting for the transfers of great amounts of data. It can take place at various levels On the HTTP level: HTTP compression; this compression is not always made

available by receiving HTTP software (IIS for instance), On the SOAP level : SOAP header is transmitted uncompressed whereas the content

(SOAP body) is compressed. In order for the systems to be interoperable, it is necessary that the algorithms used by the partners are symmetrical. The recommended compression algorithm is GZIP because of its support on the majority of the platforms.Due to the large number of implementations (SIFs, B2B, PEN), it was decided to focus on HTTP compression should performance reasons make compression necessary.


BusinessBusiness

Sender Receiver

HTTP

SOAP

HTTP

SOAP

Notification without WS-RM (Pseudo One Way)

Messaging Messaging

Logical flow

Physical flow

Technical response

Functional notification

Store and Forward Idempotence


4.2.3 POW ISSUES AND GENERAL ERROR PROCESSING

o If a POW request message does not get a response within a given delay (named “T2” in the current document) or if it received a System fault, it has to retry sending the message after having waited for a retry interval (named “T3” in this document). If the number of retries goes beyond a given limit, the sending is abandoned.

o The sender of a POW message has a guarantee that its message has been received by the B2B system when receiving the corresponding response message. This does not mean that the target receiver has received the message at that time. Besides, the absence of response does not mean that the B2B platform has not received the message. In such circumstance, if the message had been received by the B2B, the remote partner will also receive it, in which case the sender might receive a business response before having received the confirmation that its request message was successfully transmitted.


Business

Sender Receiver

HTTP

SOAP

Business

HTTP

SOAP

Request-Reply without WS-RM

Functional response

Functional request

Logical flowPhysical flow

Optional Store and Forward

Business handling

Idempotence


Figure 6: "Unexpected" business response

o When sending multiple POW messages to its partner, it can happen that the messages are delivered in a different order at the receiving end due to the fact that the B2B forwards the messages without coping for synchronisation of received messages.

o If career DB or SIF receives a validation fault from its immediate partner application after sending a POW request message, there is no reason to retry sending it again since there is no chance to get another result without a human intervention.

o If the B2B receives a validation fault after forwarding a POW request message , the sender cannot be immediately aware of this issue and will be notified by the receiving end through a business response containing an error code or through the emergence of a timeout.

o When a FluxSyncFault occurs on the receiving end when processing a POW request message, the received can notify the sending partner with a SignalSyncFault (POW) technical message.

4.2.4 BULK LOAD PROTOCOL SPECIFICITIES

The protocols used for the previously mentioned career database application bulk upload use cases all have a similar behaviour:

- There is no specific bulk session startup exchange. The sender (always the SIF) may however poll the B2B system for availability of the B2B platform before starting the bulk transmission though the use of the B2B “AliveCheck” query.

- The business data is transmitted within message having all the same structure for a given use case and containing each a subset of the data tuples to be transmitted. These messages are called “chunks”.



- The chunks are transmitted to the B2B system using the POW pattern which means that the sender transfers the delivery ownership to the B2B as soon as it gets the POW response back.

- The chunks are transmitted by the B2B to the receiver (CDBA) using the POW pattern.

- The receiver has to manage a chunk table in order to evaluate the transmission completion status. The transfer is considered compete by the receiver if all chunks having a sequence number equal or less than the last one (maked with “IsLast”=”true”) are received.

- The sender does not know if the receiver has received all chunks until a bulk transfer acknowledgement message is received from the receiver through the B2B system. This message is produced by the receiver after having received all chunks and performed a schema and business pre-validation of the chunks content (see validations for the different use case below).

- The receiver does not send an acknowledgement message if some chunks are still missing after the allocated delay for receiving all chunks is expired. In this case the receiver application manager should contact the managers of both the B2B and sender applications in order to identify the issue. If the missing chunks can be easily released, the process is restarted and the acknowledgement produced on reception of the previously missing chunks. If the problem is more intricate, the full bulk upload must be restarted from the sender end and the previously sent chunks must be discarded at all steps.

- The produced acknowledgement may notify the sender that part or all of the transmitted chunks are invalid. The receiver decides to process the valid chunks depending on the number and the severity of the exceptions.

- The acknowledgement pacing is RR in order to avoid encountering race conditions between the acknowledgement and the load report.

- A POW load report is always transmitted by the receiver after having processed the received data, even if no data were loaded for any reason. The load report contains the loading exceptions (errors and warnings) if the loading was started.



5. SCENARIOS

5.1 INTRODUCTIONThe data exchange use cases introduced before are implemented by all involved parties, i.e. the SIFs, the B2B platform and the PEN application. As seen by the sender application, the B2B platform behaves transparently as if the receiver application were directly addressed with the noticeable exception that due to B2B POW invocations, the order of delivered messages can be different compared to the order of sent messages.

This chapter provides a full description of each scenario. The corresponding WSDL as well as sample messages are found as appendixes at the end of the document.

Notice that the initial load process can be performed by two different means, one of which to be chosen by the SIF prior to implementation.

Manual file transfer

« Bulk » transfer

The RSVZ will implement both scenarios as described in this chapter.

5.2 SUMMARY

The exchange scenarios to implement are summarized in the following table:

Scenario FluxDefinition.Name Type of application protocol OperationsInitial upload (B2B) InitialUpload Bulk career ► UploadFullCareers (POW)

◄ AcknowledgeCareersUpload (RR)◄ ReportCareersUpload (POW)

Initial load (manual) Manual ► CreateAllCareers ◄ ReportCareersCreation

Single Career Upload

SingleCareer Mixed POW ► UploadFullCareer (POW)◄ ReportCareerUpload (POW)

Full careers upload BulkCareers Bulk career ► UploadFullCareers (POW)◄ AcknowledgeCareersUpload (RR)◄ ReportCareersUpload (POW)



Full career refresh RefreshCareer Mixed POW ◄ RequestRefreshCareer (POW)► UploadFullCareer (POW)◄ ReportCareerUpload (POW)

Quarterly upload QuarterlyUpload Bulk career ► UploadCareersQuarter (POW)◄ AcknowledgeQuarterlyUpload (RR)◄ ReportQuarterlyUpload (POW)

Career download Request-Reply ► RequestCareerInfo (RR)◄ return(RequestCareerInfoResponse)

74L signal Mixed POW ◄ SignalChange (POW)► SignalChange (opt) (POW)

Other signals Mixed POW ◄ SignalChange (POW)



5.3 MANUAL INITIAL LOAD

5.3.1 PROCESSThe manual initial load process is run as follows:

The SIF prepares the career data to transfer to RSVZ, optionally split it into one or more transmission blocks, format these to an XML layout described below and copies those XML to files on a transportable storage device like a CD-ROM a DVD or an USB key.

At RSVZ, the files are extracted and their content loaded in to the career database by an ETL loading application after being controlled for validity and submitted to the agreement of the application manager.

A validation and loading report is produced for each received file by the loading application at RSVZ and manually transmitted to the SIF.

5.3.1.1 Constraints The tuples provided by the SIF are all validated by RSVZ-INASTI before starting the

database loading:o The loading step will not be started if the number of records rejected during this

validation step exceeds a variable threshold depending on the number of transferred careers. The formula to be parameterized in advance is available in appendix.

o If the number of records rejected during this validation step does not reach that threshold, the loading step will be started and an on-line motivated full career refresh request will be instantiated by RSVZ-INASTI for each rejected record.

o In any cases the SIF will be informed of the error cause for each rejected SSIN within a load report sent manually (mail, …).

The physical device carrying the initial load data must be securely transmitted from the SIF to RSVZ-INASTI in order to reduce the risk of disclosing confidential data.

In order to enforce confidentiality, the data written to the physical device will be compressed using Gzip and then encrypted using the Rijndael (AES) algorithm with a 256 bits key.

The physical device provided by the SIF will be returned to it as soon as the data are loaded into the central career database.

Initial load should normally occur only once, but it is admitted that supplemental initial loads are allowed for instance when a large number of errors are detected on a previous occurrence.Sequencing information is present in the Initial load data structure to allow controlling the repetition of initial loads and to also allow

o loading the data by transmitting it in multiple files o replacing already provided information.

RSVZ-INASTI can therefore delete some database content on SIF request before loading:o When receiving a new set of files (marked with an incremented value of

InitialLoadNr), the full career database is cleaned for the SIFo When receiving a second occurrence of a given file, only those careers that

belonged to that file (marked with the same FileNr) are deleted and replaced with the newly transmitted careers

It is not mandatory to split the initial load into multiple files; the SIF can choose to send all data in one single file.



5.3.1.2 EncryptionThe XML file holding the career data must be processed before copying it to the transportable storage medium as follows:

- The produced XML must be formatted with UTF-8 encoding and stored as a file on a computer running Microsoft Windows running the Winzip software which version is capable of encrypting the file with a 256 bits AES key.

- The file must then be compressed and encrypted using the mentioned Winzip program with a 256 bits AES key resulting from entering a password that conforms the following pattern:

o <Header>-<Environment>-<SIFCode>-<Secret string> , where <Header> = the “Careers IL” constant <Environment> = the processing environment that can take the following

values : « TEST » « PROD » « ACC »

<SIFCode> = the 3 digits SIF identification code <Secret string> = a secret password allocated by the SIF and which can

vary depending of the processing environmento Example :

Careers IL-TEST-019-Secret


FileNr=1

All careers for attempt (InitialLoadNr) = 1

Files in Attempt 1


FileNr=2 FileNr=mFileNr=m-1

FileNr=1Files in Attempt 2 FileNr=nFileNr=n-1

Careers in files

Careers in files

……….

……….

…..

…..

…..

…..

… …


5.3.1.3 Sequence

The data production, transmission and loading sequence for one file is described by the following sequence diagram.

Figure 7: Manual transfer and load sequence



5.3.2 VALIDATIONSpecific to initial upload:

Before loading, the value of both InitialUploadNr and FileNr are automatically checked a. If the value of InitialUploadNr is greater than any already received value of

InitialUploadNr, the creation is submitted to an application manager and rejected with ReturnCode = “NotAllowed” if refused by her.

b. If the value of InitialUploadNr is less than the last accepted value of InitialUploadNr, the creation is rejected with ReturnCode = “AlreadyProcessed”

c. If the value of InitialUploadNr is equal to the last accepted value of InitialUploadNr, and the value of FileNr was already received for this InitialUploadNr, the creation is submitted to an application manager and is rejected with ReturnCode = “AlreadyProcessed” if refused by her.

d. In all other cases, the global creation is accepted (some careers might however be rejected for business reasons).

Initial load rejected by operator or loading program for any reason (already processed, schema validation error, …) are manually notified to the SIF.

Other validations, see 5.5.4.

5.3.3 DATA STRUCTURES1

There is no process flow (“Flux”) defined for the manual initial load since all messages are exchanged manually. Data structures for the manual initial load encompass the following XML:

The CreateAllCareers structure used to store the full data to load in the career database for a given SIF

The ReportCareersUpload structure used to provide reporting information to the SIF after loading.

5.3.3.1 Career creationThe career creation XML file structure has a layout similar to the bulk and single career upload message layout with the following particularities:

A specific root node “CreateAllCareers“ Initial load sequencing information (InitialLoadNr, FileNr) is added

Figure 8: CreateAllCareers general structure

5.3.3.2 Load report



Figure 9: Career creation report structure

5.3.4 DATA CONTENTS

See 5.5.7.3. for data common to initial load and bulk upload.Specific to the initial load are:

o In the CreateAllCareers structure:o InitialLoadNr : loading attempt number – a new value implies deleting the whole

databaseo FileNr : Set of careers to load – if chosen by the SIF, the initial load can be split into

multiple files. This field identifies each file which sequence must start with 1 without holes. Its absence means that there is no splitting into files.

o In the ReportCareersCreation structure:o InitialLoadNr and FileNr are copied from the received CreateAllCareers XMLo GenerationTime contains the time when the report was createdo ReturnCode gets the load return code (see values in 5.5.4)o ProcessedCareersNr is filled with the number of received careers within the fileo Rejected is a structure containing all rejected careers if any.

5.3.4.1 Data values



Input data structure1:

Node Parent node Nbr Value restrictions Value to setCreateAllCareers Document 1SIFCode CreateAllCareers 1 3 alphanumeric

charactersSIF code (ex: “900”)

InitialLoadNr CreateAllCareers 0..1 Defined by xs:positiveInteger

Initial load occurrence number

FileNr CreateAllCareers 0.1 Defined by xs:positiveInteger

Identification of subset of careers if all careers are not transmitted at once.

IndividualRights CreateAllCareers m Number = number of subject persons in file

CreationTime IndividualRIghts 1 Defined by xs:dateTime Time of career data creation

BeginValidityDate IndividualRIghts 1 Defined by xs:date Date from which provided career is valid

SubjectPerson IndividualRights 1 Person identificationLastName SubjectPerson 0..1 StringFirstName SubjectPerson 0..1 StringSSINType SubjectPerson 1 « NN » or « BIS » Type of SSINSSIN SubjectPerson 1 11 digits String SSIN identifying subject

personBirthDate SubjectPerson 0..1 Defined by xs :dateCareerDetail IndividualRights 1 ..

mCareer period detailSee [REF1] for settings

PeriodKind CareerDetail 1 Value listBeginYear CareerDetail 1 Value between 1956 and

2080Period begin Year

BeginQuarter CareerDetail 0..1 « Q1 » to « Q4 » Period begin quarter, Q1 assumed if not set

EndYear CareerDetail 1 Value between 1956 and 2080

Period end Year

EndQuarter CareerDetail 0..1 « Q1 » to « Q4 » Period end quarterQ4 assumed if not set

Income1 CareerDetail 0..1 AmountIncome2 CareerDetail 0..1 AmountCumulatedIncome CareerDetail 0..1 AmountTemporaryInd CareerDetail 0..1 Defined par xs :booleanReferenceYear CareerDetail 0..1 Value between 1900 and

2080Reference year for income estimation

LatePaymentDate CareerDetail 0..1 Defined by par xs :date Always set in option A, set if option B and ongoing pension calculation

FPSControlInd CareerDetail 0..1 Defined by xs :boolean Always set in option A, set if option B and ongoing pension calculation

1 Cardinality (« Nbr » column) shows the actual cardinality in the current use case, not the value defined within the schema which that can be shared by several use cases.



Node Parent node Nbr Value restrictions Value to setUncondPen IndividualRights 0..1Amount UncondPen 1 Amount Unconditional pension

amountPayBeginDate UncondPen 0..1 Defined par xs :datePayEndDate UncondPen 0..1 Defined par xs :date

Report data structure: see 5.5.7.3. The SIFCode, InitialLoadNr and FileNr are filled with the data received in the input data document.

5.3.5 QUANTITATIVE DATA

Before encryption, the size of a file containing 100,000 careers and encoded in UTF8 is About 500 Mbytes for 6 periods per career About 700 Mbytes for 10 periods per career.

2



5.4 BULK INITIAL LOAD

5.4.1 PROCESSThe bulk initial load is an extension of the bulk full career upload (see 5.5) in that it reuses the application protocol and the data layout with some minor changes and constraints:

Initial load should normally occur only once, but it is admitted that supplemental initial loads are allowed for instance when a large number of errors are detected on a previous occurrence. RSVZ-INASTI will therefore

o Condition the loading process part of the initial load to a manual interventiono Delete all or part of the database content related to the SIF before loading

The tuples provided by the SIF are all validated by RSVZ-INASTI before starting the database loading:

o The loading step will not be started if the number of chunks or records rejected during this validation step exceeds a variable threshold depending on the number of transferred careers. The formula to be parameterized in advance is available in appendix 7.3.1.

o If the number of records rejected during this validation step does not reach that threshold, the loading step will be started and an on-line motivated full career refresh request will be instantiated by RSVZ-INASTI for each rejected career.

o In any cases, the SIF will be informed of the error cause for each rejected SSIN within a load report sent as part of the bulk upload protocol.

5.4.2 SEQUENCESee 5.5.1.2.

5.4.3 VALIDATIONSpecific to initial upload:

Initial load rejected by operator for any reason (already processed for instance) are rejected with error code “NotAllowed”.

Other validations, see 5.5.4.

5.4.4 DATA

5.4.4.1 OperationsThe operations involved in the Initial Upload process are the following:

UploadFullCareers, from SIF to RSVZ, repeated for each chunk to transfer AcknowledgeCareersUpload, from RSVZ to SIF, invoked after all chunks are received

and validated at chunk level ReportCareersUpload, from RSVZ to SIF, invoked after validation and loading of all

careers found in chunks

5.4.4.2 Data structuresWith exception of initial load sequencing information (InitialLoadNr and FileNr), the above operations are related to SOAP body literal messages which structure are shared with the bulk full career upload process. See 5.5.7.2.

5.4.4.3 Data content



Like for the manual initial load, the InitialLoadNr field defines the initial load attempt. The FileNr field must be absent for a bulk initial upload.Splitting the initial load can be achieved by using a distinct value of Block SequenceId to each set of data to upload. Duplicate initial loads lead to replacement (delete and insert) of related data after human intervention and agreement.



5.5 BULK FULL CAREER DATA UPLOAD

5.5.1 PROCESSBulk full career data upload happens when the SIF has to refresh many individual records at once. The automated initial load is an extension of this kind of upload.The upload is performed in the following sequence:

SIF: Preparation of data to be transmitted SIF: Upload of grouped full career records within multiple messages named “chunks” RSVZ : Collect all career records RSVZ : Transmission of a bulk upload acknowledgement to SIF RSVZ : Load all career records RSVZ : Transmission of a load report to SIF

5.5.1.1 Process details The loading process is initiated by the SIF by

o Attributing an identification value (“FluxID”) to the new “Flux”o Attributing an identification for the bulk transfer (SequenceID)o Start looping preparing and sending chunks each containing a given number (for

instance 500) of careers. An upload response is expected from the immediate partner (B2B) for each

sent chunk If this response is not received within delays, the messages must be

repeated by the SIF at a pace to be agreed3 until either a response is received or the maximum number of retries4 is reached.

If the maximum number of retries is reached or a ValidationFault exception is received, the transfer is suspended by the SIF but should be able to be restarted from the beginning or from the current situation by a joint manual intervention implicating SIF, B2B and PEN application managers.

When all chunks are sent, the SIF starts waiting for a business acknowledgement while all chunks are forwarded by the B2B to the PEN Career database application.

The PEN career database application collects all chunks and sends a receipt (acknowledgement) message back to the SIF when all chunks are received.

o If not all chunks are received within a given delay, the PEN application notifies an application manager through the monitoring system. The process can be restarted or aborted depending on the error encountered and after having agreed on the solution with the B2B and SIF application managers.

o If some chunk level errors are detected by the Career DB application, the business acknowledgement will notify the SIF of these errors. This does not preclude loading (if possible) of data and sending of the career loading report to the SIF.

The PEN receipt is transported in request-reply mode to keep the acknowledgement and future load report correctly sequenced at the SIF side.

The PEN application then validates and loads all received career records into the database before sending the load report message to the SIF. A report response is expected from the immediate receiving partner to terminate the process.



Notice that FluxID uniquely identifies a set of correlated messages of the same or of different type that all belong to the same process instance or conversation (it is an end-to-end process instance correlation identifier)Block.SequenceID correlates data chunks in a bulk upload. In most situations, both FluxID and SequenceID could have the same value but, if a process had encompassed more than one bulk transfer (this is not the case in the career data exchanges), the same FluxID value would have been shared by more than one SequenceID value.



File 1 – Attempt 1 careers

……….

Chunks in sequence

Careers in chunk 1

Block.SequenceNumber = 3

FileNr = 1Files in attempt 1 FileNr = 2 FileNr = 3

Block.SequenceID = XYZ




5.5.1.2 SequenceThe following diagram shows the sequence of operations at application level by the 3 involved systems:

Figure 10: Bulk upload application level sequence diagram

The following diagrams show the sequence of operations and the possible errors of a generic bulk upload between a SIF and the PEN application through the B2B first at the SIF side when uploading the career chunks and then at the PEN side when processing the chunks. The bulk upload of full career records follows the same pattern.



Figure 11: Bulk transfer sequence details - SIF side



Figure 12: Bulk upload sequence details - PEN side

Notice that an upload acknowledgement will always be followed by a load report even if the acknowledgement returns a “TooManyErrors” return code. In this case however, the report will contain no exceptions instead of providing a potentially huge number of those.

5.5.2 FLOW MANAGEMENTFor a bulk transfer:



- the FluxID identifies all messages related to the transfer occurrence in both directions (transmission identification).- the Block SequenceID correlates the set of data generated by the SIF (it is the data generation batch identification).

Note that one batch could be transferred twice or more, using different Flux Ids for each transmission. The block sequence id may not change within a FluxID but the same SequenceID can be reused with a new FluxID in case of process restart.

5.5.3 STATE MACHINE ON SIF SIDEThe following diagram describes the bulk upload processing at the SIF side, including the error processing. This diagram mixes both SIF application and B2B protocol management behaviours in order to show their interactions.

Figure 13: Bulk Upload SIF State Diagram



5.5.4 VALIDATIONS AT CAREER DB SIDE

The bulk transfers will be validated first at chunk level and then at career level by the PEN application before starting the load process.

- If the career level validation fails with a high score, the load will not be performed at all- If the career level validation fails with a low score, the valid tuples will be loaded into the

databaseScores will be determined by

- The severity of the error5

- The number of errors

Validations types are described below:

Chunk level validation1. All career data in chunks having a Block Sequence ID different from the previously used

value in the same flux are rejected with ErrorCode “InvalidSequence”.Chunks having the same (Flux Name, FluxID, Block SequenceID, Block SequenceNumber) as previously received messages are duplicate business messages and will be dropped by the PEN business layer. An monitoring event will be raised.

2. Chunks with the same (Flux Name, Flux Id, Block SequenceId) and a different Block SequenceNumber with the same business content are rejected with error code “DuplicateData”.

3. If a schema validation error happens when receiving an UploadFullCareers request, a validationFault is returned to the B2B system but some processing might occur depending on how far the chunk can be parsed. Anyway, no data will be loaded and if some parsing is achievable, a “ValidationError” error code will be returned for the chunk. Impossible parsing will result in the emergence of an acknowledgement timeout on the SIF side. Such situation can occur when the schema definitions are desynchronized between the B2B and the career database application or when the schema usage is not correct at the SIF side in which case the schema is syntactically correct but semantically not (wrong usage of xs:choice option for instance).

Career level validation1. Received full career data for a given subject person are validated as follows

- Birth date > current date - 16 years, if provided => ErrorCode = “InvalidBirthDate”- CreationTime > current time1 => ErrorCode = “InvalidCreationTime”- Begin validity date > current date => ErrorCode = “InvalidBeginDate”- For each career period

a. end period is before begin period => ErrorCode = “InvalidPeriod”b. end period year is greater than current year + 1 => ErrorCode = “LatePeriod”c. Provided career periods overlap => ErrorCode = “PeriodOverlap”

- Unconditional pension pay begin date > pay end date, if provided => ErrorCode = “InvalidPayDate”

2. The SIF membership is validated by the PEN Career DB application upon reception of career uploads as follows: if period kind is not "Delete", career detail quarters must fall within known membership period. If not, the whole career is rejected with error code « AffiliationMismatch ». If no affiliation is found for the SIF but the person is known to the career DB, the whole career is rejected with error code “NoAffiliation”.

1 The times must be synchronised to keep this test valid in all circumstances. This must be achieved by using UTC times in data exchanges and by synchronizing the servers with Stratum 1 solutions.



3. If the received SSIN or BIS is not found in the career DB but has a corresponding record in the SSIN history, the career will be loaded and attributed to the right person as if the right SSIN were sent by the SIF. A specific warning code “SSINChanged” will be transmitted together with the new person identification data.

4. If the received SSIN or BIS is not found in the career DB and has no corresponding record in the SSIN history, the career will be rejected with error code “UnknownPerson” and a career DB application manager will be notified of that issue that might result from an unknown SSIN change.

5. If the action is to delete a period, it is checked that the period already exists in the career database, otherwise, an error code “UnknownPeriod” is produced for the career and no data of that career is loaded.

6. It is required to provide the whole career within each “full career” transmission. It is therefore checked that all non-deleted periods existing in the database are submitted for update in the transmitted data. If not, an “IncompleteCareer” error is returned and the SIF should subsequently start a career download to recover from such desynchronisation.

7. An information tuple provided by the SIF will be loaded within the database if it is valid (see other business validation rules) and if the creation time of the received information is more recent than the persisted creation time and if the validity date of the received information is equal or more recent that the persisted validity date. Career data rejected for this reason will get a warning exception with reason code “OldData”.

8. Within a bulk upload, all career periods related to one given person must be concentrated within one IndividualRights node. When the eCLIPZ application detects careers elements within distinct IndividualRights:

a. None of the career elements from the corresponding person are loadedb. Any redundant career data is rejected with code “DuplicateRights”

Process level validationBoth chunk level and career level validations are performed at message or career level. A global validation summary is worked out for the whole bulk processing and exposed by a return code provided in both the bulk load acknowledgement (for chunk validation) and in the loading report (for load validation). Its values are: 1. “OK” if no error is was detected.2. “TooManyErrors” if the number of errors is above a predefined threshold (chunks threshold

or careers threshold), in which case the whole bulk upload is rejected.3. “SomeErrors” if some errors were detected, but not enough to reach the corresponding

threshold. All careers but those where errors were detected will be loaded.4. “NotAllowed” if not all chunks were received within the allowed delays and after intervention

of an administrator on the eClipz side who decided to cancel the upload. The whole bulk upload is then rejected.

5.5.5 VALIDATIONS AT B2B SIDE

The B2B does not perform any other validation than schema conformance of received messages in both directions.



5.5.6 VALIDATIONS AT SIF SIDE

Upon reception of the upload acknowledgement and load report messages, the SIF performs schema conformance validation and sends a ValidationFault back if necessary.If the message is valid, the received message must be answered by the SIF with a AcknowledgeCareersUploadResponse (RR) or ReportCareersUploadResponse (POW) depending on the received message type.

5.5.7 DATA

5.5.7.1 OperationsThe operations involved in the bulk full career upload process are the following:

UploadFullCareers, from SIF to RSVZ, repeated for each chunk to transfer AcknowledgeCareersUpload, from RSVZ to SIF, invoked after all chunks are received

and validated at chunk level ReportCareersUpload, from RSVZ to SIF, invoked after validation and loading of all


5.5.7.2 Data structuresThe above operations are related to SOAP body literal messages which structure have the standard B2B layout, i.e.

Start with the “ApplHeader” structure for the request messages (see [REF2]) Followed by the “FluxDescriptor” structure that maintains process context (see

[REF2]) in the request messages only. Followed by the “Block” structure for the bulk load chunk messages (see [REF2]) Followed by the specific business structure here named

o “UploadCareersData” for the bulk load chunkso “UploadAcknowledgementData” for the upload acknowledgement request

messageo “ReportData“ for the load report message



Figure 14: Structure of UploadCareerData element

Figure 15: SubjectPerson structure



Figure 16: Structure of CareerDetail element

Figure 17: Structure of UploadAcknowledgementData



Figure 18: Structure of ReportData element

5.5.7.3 Data values

Upload messages1:

Node Parent node Nbr Value restrictions Value to setUploadFullCareers Document 1ApplHeader UploadFullCareers 1Timestamp ApplHeader 1 Defined by par

xs:dateTimeDate and time of message creation

Origin ApplHeader 1Organization Origin 1 3 alphanumeric


Application Origin 1 String (max 11 characters)

“1202”

Destination ApplHeader 1Organization Destination 1 3 alphanumeric

charactersRSVZ/INASTI = “000”6

Application Destination 1 String (max 11 characters)

“1202”

MessageID ApplHeader 1 Up to 15 alphanumeric characters

Value unique to the message, chosen by the SIF

1 Cardinality (« Nbr » column) shows the actual cardinality in the current use case, not the value defined within the schema which that can be shared by several use cases



Node Parent node Nbr Value restrictions Value to setUserID ApplHeader 1 Chosen by the SIFRequestInitiatorID ApplHeader 0FluxDescriptor UploadFullCareers 1Initiator FluxDescriptor 1Organization Initiator 1 3 alphanumeric


Application Initiator 1 String (max 11 characters)

“1202”

FluxID FluxDescriptor 1 Up to 36 alphanumeric characters

Unique identification of upload process

FluxDefinition FluxDescriptor 1Name FluxDefinition 1 Up to 36 alphanumeric

characters“InitialUpload” or “BulkCareers”

Version FluxDefinition 1 Defined by xs:int 1Block UploadFullCareers 1 SequenceID Block 1 Up to 36 alphanumeric

charactersEx: “Init-090401-001”

SequenceNumber Block 1 Positive integer 1 to number of chunksIsLast (attribute) Block 1 Boolean True for last created

chunk, false or absent for the other ones1

UploadCareersData UploadFullCareers 1ChangeReason UploadCareersData 1 “InitialLoad” for initial

load Careers UploadCareersData 1 Careers data wrapper

nodeIndividualRights Careers 1..n Number <= max number

of subject persons in chunks

Typical value = 500

CreationTime IndividualRIghts 1 Defined by xs:dateTime Time of career data creation

BeginValidityDate IndividualRIghts 1 Defined by xs:date Date from which provided career is valid

PersonIdentification IndividualRights 1 Person identificationLastName SubjectPerson 0..1 StringFirstName SubjectPerson 0..1 StringSSINType SubjectPerson 1 « NN » or « BIS » Type of SSINSSIN SubjectPerson 1 11 digits String SSIN identifying subject

personBirthDate SubjectPerson 0..1 Defined by xs :datePersonNewIdentification

IndividualRights 0 Not used in unsolicited uploads

CareerDetail IndividualRights 1 ..m

Career period detailSee [REF1] for settings

BeginYear CareerDetail 1 Value between 1956 and Period begin Year

1 IsLast eases the SIF business application to extract the career details in a streaming mode in which case the number of chunks is not known upfront. When the last chunk is detected by the sender business application, the related SequenceNumber reflects the number of chunks to expect even if they are received unordered at the receiving side. If the chunks are prepared before starting the sending, the IsLast flag has to be set by the sender for the chunk with the highest SequenceNumber.



Node Parent node Nbr Value restrictions Value to set2080



Period end Year


PeriodKind CareerDetail 1 Value listIncome1 CareerDetail 0..1 AmountIncome2 CareerDetail 0..1 AmountCumulatedIncome CareerDetail 0..1 AmountTemporaryInd CareerDetail 0..1 Defined par xs :booleanReferenceYear CareerDetail 0..1 Value between 1900 and




UncondPen IndividualRights 0..1Amount UncondPen 1 Amount Unconditional pension


Notice that quarters can be grouped into one period if their content do not change within that period. Amounts provided are always annual amounts and are defined as xs:decimal restricted to max 10 digits with 2 mandatory decimals.

Upload acknowledgement message:

Node Parent node Nbr Value restrictions Value to setAcknowledgeCareersUpload

Document 1

ApplHeader AcknowledgeCareersUpload

1

Timestamp ApplHeader 1 Defined by par xs:dateTime

Date and time of message creation


charactersRSVZ/INASTI = “000”


“1202”



Application Destination 1 String (max 11 “1202”



Node Parent node Nbr Value restrictions Value to setcharacters)


Value unique to the message, chosen by the PEN application

UserID ApplHeader 1 Chosen by PENRequestInitiatorID ApplHeader 0 Not usedFluxDescriptor AcknowledgeCaree

rsUpload1

Initiator FluxDescriptor 1Organization Initiator 1 3 alphanumeric



“1202”




characters“InitialUpload” or “BulkCareers”

Version FluxDefinition 1 Defined by xs:int 1UploadAcknowledgementData

AcknowledgeCareersUpload

1

GenerationTime UploadAcknowledgementData

1 Defined by par xs:dateTime

Date and time of upload validation

BlockSequenceID UploadAcknowledgementData

1 Up to 36 alphanumeric characters

Value from upload requests

ReceivedChunksNbr UploadAcknowledgementData

1 Defined by xs:positiveInteger

Number of chunks received by PEN

ReceivedCareersNbr UploadAcknowledgementData


Total number of careers received in all chunks

ReturnCode UploadAcknowledgementData

1 Global return code “OK” or error determined by process level validation (see 5.5.4)

Rejected UploadAcknowledgementData

0..n Chunks rejected

BlockSequenceNr Rejected 1 String Identification of rejected Chunk

ErrorCode Rejected 1 Value list – Error code related to rejected chunk

Error determined by process level validation (see 5.5.4)

Upload acknowledgement response message:

Node Parent node Nbr Value restrictions Value to setAcknowledgeCareersUploadResponse

Document 1

ApplHeader AcknowledgeCareersUploadResponse

1



Origin ApplHeader 1



Node Parent node Nbr Value restrictions Value to setOrganization Origin 1 3 alphanumeric



“1202”




“1202”


Value unique to the message, chosen by the SIF application

UserID ApplHeader 1 Chosen by SIFRequestInitiatorID ApplHeader 0 Not used

Load report message:

Node Parent node Nbr Value restrictions Value to setReportCareersUpload

Document 1

ApplHeader ReportCareersUpload

1






“1202”




“1202”



UserID ApplHeader 1 Chosen by PENRequestInitiatorID ApplHeader 0 Not usedFluxDescriptor ReportCareersUplo

ad1




“1202”



FluxDefinition FluxDescriptor 1Name FluxDefinition 1 Up to 36 alphanumeric “InitialUpload” or



Node Parent node Nbr Value restrictions Value to setcharacters “BulkCareers”

Version FluxDefinition 1 Defined by xs:int 10ReportData ReportCareersUplo

ad1

GenerationTime ReportData 1 Defined by par xs:dateTime


ReturnCode ReportData 1 Global return code “OK” or error determined by global detailed validation (see 5.5.4)

ProcessedCareersNbr

ReportData 1 Defined by xs:positiveInteger

Number of careers processed independently of processing success

Exceptions ReportData 0..1 Wrapper node for exceptions

Exception Exceptions 1..n Careers which processing requires feedback

IsLoaded (Attribute) Exception 1 xs:boolean True is career was loaded anyway, false if it was not loaded

Severity (Attribute) Exception 1 Value list Indicator to distinguish errors from warnings

ReasonCode Exception 1 Value list Reason why career processing is exceptional

PersonIdentification Exception 1 Identification provided by the SIF of the person for which career loading is in exception

LastName PersonIdentification

0 Not used in current context

FirstName PersonIdentification


SSINType PersonIdentification

1 « NN » or « BIS » Type of SSIN

SSIN PersonIdentification

1 11 digits String SSIN identifying subject person

BirthDate PersonIdentification


PersonNewIdentification

Exception 0..1 Identification of that same person as currently known by RSVZ if more recent

LastName PersonNewIdentification

1 Last name in new identification

FirstName PersonNewIdentification

1 First name in new identification

SSINType PersonNewIdentification


SSIN PersonNewIdentification

1 11 digits String SSIN in new identification

BirthDate PersonNewIdentific 1 Defined by xs :date Date of birth as known by



Node Parent node Nbr Value restrictions Value to setation RSVZ



5.6 QUARTERLY UPLOAD

5.6.1 PROCESSThe quarterly upload process is triggered every quarter by every SIF in order to send the earnings from all its active affiliates for the elapsed quarter.Like all bulk loads initiated by the SIFs, a flawless quarterly upload is performed in the following sequence:

SIF: Preparation of data to be transmitted SIF: Upload of grouped quarterly earnings records within multiple messages named

“chunks” RSVZ : Collect all earnings records RSVZ : Transmission of a bulk upload acknowledgement to SIF RSVZ : Load all quarterly earnings records RSVZ : Transmission of a load report to SIF

Process detail, sequence, state machine and flow management are the same as for a bulk full career upload. See 5.5.

5.6.2 VALIDATIONS AT CAREER DB SIDEChunk level validation

1. All chunks must have the identical values for Year and Quarter attributes.If a chunks arrives with a different value for Year or Quarter for a given SIF and within the same flux, the chunk is rejected with ErrorCode = “QuarterMismatch” and none of its content will be loaded

2. All career data in chunks having a Block Sequence Id different from the previously used value in the same flux are rejected with ErrorCode “InvalidSequence”.Chunks having the same (Flux Name, Flux Id, Block SequenceId, Block SequenceNumber) as previously received messages are duplicate business messages and will be dropped by the PEN business layer. An monitoring event will be raised.

3. Chunks with the same (Flux Name, Flux Id, Block SequenceId) and a different Block CurrentSequenceNbr with the same business content are rejected with error code “DuplicateData”.

4. The Year and Quarter values may must be those of the last received quarter or the next one, provided that the quarter is elapsed. Otherwise, the chunks are rejected with ErrorCode “OldQuarter” or “EarlyQuarter”.

5. If a schema validation error happens when receiving an UploadCareersQuarter request, a validationFault is returned to the B2B system and some processing might occur or not depending on how far the chunk can be parsed. Anyway, no data will not be loaded and if some parsing can occur, a “ValidationError” error code will be returned for the chunk. Impossible parsing will result in the emergence of an acknowledgement timeout on the SIF side.

Career level validation1. Received quarter data for a given subject person are validated as follows- CreationTime > current time => error exception with reason = “InvalidCreationTime”- PeriodKind may not be “Delete” => error exception with reason = “InvalidPeriodKind”

2. The SIF membership is validated by the PEN Career DB application upon reception of quarterly uploads as follows: quarter must fall within known membership period. If not, the quarter is rejected for that person with error exception with reason « AffiliationMismatch »



3. An quarter provided by the SIF will be loaded within the database if it is valid (see other business validation rules) and if the creation time of the received information is more recent than the persisted creation time. Quarterly data rejected for this reason will get a warning exception with reason code “OldData”.

4. If the received SSIN is not found in the career DB but has a corresponding record in the SSIN history, the quarter will be loaded and attributed to the right person as if the right SSIN were sent by the SIF. A specific warning code “SSINChanged” will be transmitted in the report together with the new person identification data.

5. If the received SSIN or BIS is not found in the career DB and has no corresponding record in the SSIN history, the career will rejected with an error exception with reason “UnknownPerson” and a PEN application manager will be notified of that issue that might result from an unknown SSIN change.

6. It is not allowed to send the quarter records of one given person more than once. When the eCLIPZ application detects duplicates:

a. None of the quarter records from the corresponding person are loadedb. Any redundant quarter data is rejected with code “DuplicateRights”

5.6.3 DATA

5.6.3.1 OperationsThe operations involved in the bulk full career upload process are the following:

UploadCareersQuarter, from SIF to RSVZ, repeated for each chunk to transfer AcknowledgeQuarterlyUpload, from RSVZ to SIF, invoked after all chunks are

received and validated at chunk level ReportQuarterlyUpload, from RSVZ to SIF, invoked after validation and loading of all




[REF2]), in request messages only Followed by the “Block” structure for the bulk load chunk messages (see [REF2]) Followed by the specific business structure here named

o “UploadQuarterData” for the bulk load chunkso “UploadAcknowledgementData” for the acknowledgement request messageo “ReportData“ for the upload report message



Figure 19: Structure of UploadQuarterData element

5.6.3.3 Data values1

Node Parent node Nbr Value restrictions Value to setUploadCareersQuarter Document 1ApplHeader UploadCareersQ

uarter1




charactersSIF code (ex : “900”)


“1202”




“1202”



UserID ApplHeader 1 Chosen by the SIFRequestInitiatorID ApplHeader 0 Chosen by the SIFFluxDescriptor UploadCareersQ

uarter1

Initiator FluxDescriptor 1Organization Initiator 1 3 alphanumeric SIF code (ex : “900”)




Node Parent node Nbr Value restrictions Value to setcharacters


“1202”




characters“QuarterlyUpload”

Version FluxDefinition 1 Defined by xs:int 1Block UploadCareersQ

uarter1

SequenceID Block 1 Up to 36 alphanumeric characters

Ex: “QU-090401-001”

CurrentSequenceNumberbr

Block 1 Positive integer 1 to number of chunks

IsLast (attribute) Block 1 Boolean True for last chunk, false or absent for the other ones

UploadQuarterData UploadCareersQuarter

1

Year UploadQuarterData

1 Attribute - Value between 1900 et 2080

Period begin Year

Quarter UploadQuarterData

1 Attribute - « Q1 » to « Q4 »

Period begin quarter

PersonQuarter UploadQuarterData

1..n Number = number of subject persons in chunks

Typical value = 500

CreationTime PersonQuarter 1 Atribute - Defined by xs:dateTime

Time of career data creation

SSIN PersonQuarter 1 Attribute - 11 digits String SSIN identifying subject person

PeriodKind PersonQuarter 1 Value list See FDSIncome1 PersonQuarter 0..1 Amount See FDSIncome2 PersonQuarter 0..1 Amount See FDSCumulatedIncome PersonQuarter 0..1 Amount See FDSTemporaryInd PersonQuarter 0..1 Defined par xs :boolean See FDSReferenceYear PersonQuarter 0..1 Value between 1900 and

2080See FDS

LatePaymentDate PersonQuarter 0..1 Defined by par xs :date Always set in option A, set if option B and ongoing pension calculation

FPSControlInd PersonQuarter 0..1 Defined by xs :boolean Always set in option A, set if option B and ongoing pension calculation

Upload acknowledgement message:

Node Parent node Nbr Value restrictions Value to setAcknowledgeQuarte Document 1



Node Parent node Nbr Value restrictions Value to setrlyUploadApplHeader AcknowledgeQuart

erlyUpload1






“1202”




“1202”



UserID ApplHeader 1 Chosen by PENRequestInitiatorID ApplHeader 0 Not usedFluxDescriptor AcknowledgeQuart

erlyUpload1




“1202”





Version FluxDefinition 1 Defined by xs:int 1UploadAcknowledgementData

AcknowledgeQuarterlyUpload

1

GenerationTime UploadAcknowledgementData

1 Defined by par xs:dateTime


BlockSequenceID UploadAcknowledgementData

1 Up to 36 alphanumeric characters

Value from upload requests

ReceivedChunksNbr UploadAcknowledgementData


Number of chunks received by PEN

ReceivedCareersNbr UploadAcknowledgementData


Total number of careers received in all chunks

ReturnCode UploadAcknowledgementData

1 Global return code “OK” or error determined by process level validation (see 5.5.4)

Rejected UploadAcknowledgementData

0..n Chunks rejected

BlockSequenceNr Rejected 1 Defined by xs:positiveInteger

Identification of rejected Chunk



Node Parent node Nbr Value restrictions Value to setErrorCode Rejected 1 Value list – Error code

related to rejected chunkError determined by chunk level validation (see 5.6.2)

Upload acknowledgement response message:

Node Parent node Nbr Value restrictions Value to setAcknowledgequarterlyUploadResponse

Document 1

ApplHeader AcknowledgeQuarterlyUploadResponse

1






“1202”




“1202”


Value unique to the message, chosen by the SIF application

UserID ApplHeader 1 Chosen by SIFRequestInitiatorID ApplHeader 0 Not used

Load report message:

Node Parent node Nbr Value restrictions Value to setReportQuarterlyUpload Document 1ApplHeader ReportQuarterlyUpload 1Timestamp ApplHeader 1 Defined by par





“1202”




“1202”


Value unique to the message, chosen by the



Node Parent node Nbr Value restrictions Value to setPEN application

UserID ApplHeader 1 Chosen by PENRequestInitiatorID ApplHeader 0 Not usedFluxDescriptor ReportQuarterlyUpload 1Initiator FluxDescriptor 1Organization Initiator 1 3 alphanumeric



“1202”





Version FluxDefinition 1 Defined by xs:int 1ReportData ReportQuarterlyUpload 1GenerationTime ReportData 1 Defined by par

xs:dateTimeDate and time of upload validation

ProcessedCareersNbr

ReportData 1 Defined by xs:positiveInteger

Total number of careers processed for loading

ReturnCode ReportData 1 Global return code “OK” or error determined by process level validation (see 5.5.4)

Exceptions ReportData 0..1 Wrapper node for exceptions

Exception Exceptions 1..n Careers which processing requires feedback

IsLoaded (Attribute) Exception 1 xs:boolean True is career was loaded anyway, false if it was not loaded

Severity (Attribute) Exception 1 Value list Indicator to distinguish errors from warnings

ReasonCode Exception 1 Value list Reason why career processing is exceptional (see 5.6.2)

PersonIdentification Exception 1 1 Identification as transmitted by the SIF

LastName PersonIdentification

0 Not used


0 Not used





BirthDate PersonIdentificatio 0 Not used

1 Old identification is sent back to the SIF when the received career is marked with an identification that is known by RSVZ-INASTI to have changed. In such case, a warning is issued (code SSINChanged), the OldIdentification node contains the identification data received from the SIF and the Identification node contains the last identification known at RSVZ-INASTI but the received career data is loaded anyway.



Node Parent node Nbr Value restrictions Value to setn


Exception 0..1 Identification of the same person as known by the RSVZ, if more recent.


1 Last name


1 Person first name





BirthDate PersonNewIdentification

1 Person birth date



5.6.3.4 Quantitative data

With UTF-8 encoding, the approximate size of data is the following : Career within a « chunk » : 520 bytes Chunk SOAP Body without career : 2000 bytes SOAP message overhead : 6000 bytes

For a transfer of 100.000 careers :

Without compression With GZIP compression

Number of careers/chunk

Number of chunks to transfer

Chunk size (KBytes)

Total bytes transferred (MBytes)

Transfer delay at 10Mbit/s (min)1

Chunk size (KBytes)

Total bytes transferred (MBytes)

Transfer delay at 10Mbit/s

(min)1 100.000 8,5 850 14 1,7 170 3

10 10.000 13,2 130 2,2 2 20 0,4100 1.000 60 60 1 9 9 0,2

1000 100 528 53 0,9 80 8 0,15

1 This delay does only take into account the line capacity and specifically does not take into account the need to wait for a technical acknowledgement at HTTP and SOAP levels before sending the next chunk. The impact of these delays can be reduced by opening multiple parallel sessions..document.doc 57 /94 Date: 07/10/2010


5.7 SINGLE CAREER UPLOAD

5.7.1 PROCESSSingle full career data upload happens when the SIF has to spontaneously refresh one individual record.The upload is performed in the following sequence:

SIF: Preparation of data to be transmitted SIF: Upload of the full career data within one message RSVZ : Validate and load all career records RSVZ : Transmission of a load report to SIF

5.7.1.1 Process details The loading process is initiated by the SIF by

o Selecting the data to uploado Attributing an identification value (“Id”) to the new “Flux” o Sending the upload message to PEN

An upload response is expected from the immediate partner (B2B) If a ValidationFault exception is received, the transfer is cancelled by the

SIF If this response is not received within delays or a SystemFault is received,

the message must be repeated by the SIF at a pace to be agreed8 until either a response is received or the maximum number of retries9 is reached.

If the maximum number of retries is reached the transfer is cancelled by the SIF but the PEN application might have handled the request and a load report might therefore be received by the SIF.

The PEN application validates and loads the received career record into the database before sending a load report message to the SIF. An upload response is expected from the immediate receiving partner to terminate the process.

5.7.1.2 Sequence

The following diagram shows the high-level exchanges between applications in the case of single career upload.



Figure 20: Single career upload sequence

The following diagram shows the detailed exchanges between applications and transport layers in the case of single career upload with various types of possible errors:



Figure 21: Detailed single career upload sequence diagram

5.7.2 FLOW MANAGEMENTFor a single transfer a Flux Name and Id identify all messages related to the transfer occurrence in both directions (transmission identification).


The validations performed are the same as the career level validations performed in the corresponding bulk upload. See § 5.5.4.

5.7.4 DATA

5.7.4.1 OperationsThe operations involved in the single full career upload process are the following:

UploadFullCareer, from SIF to RSVZ ReportCareerUpload, from RSVZ to SIF, invoked after validation and loading of the

received career


Start with the “ApplHeader” structure (see [REF2]) Followed by the “FluxDescriptor” structure that maintains process context (see

[REF2]) Followed by the specific business structure here named

o “UploadCareerData” for the career data to loado “ReportData“ for the load report message

These data structures are documented in the bulk scenario (see 5.5.7.2).

5.7.4.3 Data values



The data values are the same as for th bulk scenario (see 5.5.7.3) with the following exceptions:o Flux Name = “SingleCareer”o Number of “IndividualRights” elements = 1o ChangeReason : specific reason why the upload was triggered (see schema definition for

list of values)



5.8 CAREER REFRESH REQUEST

5.8.1 PROCESSCareer refresh is similar to the single career upload but is preceded by the sending of a refresh invitation message from the career DB application.The flawless refresh is performed in the following sequence:

RSVZ : Transmission of the refresh request SIF: Extraction of data to be transmitted SIF: Upload of the full career data within one message RSVZ : Validate and load all career records RSVZ : Transmission of a load report to SIF

Refresh requests are triggered by the career DB application for business reasons or when a prior upload error requires a reloading process.

5.8.1.1 Process detailsThe career DB application

o Allocates a new flux for the refresh processo builds a refresh request upon request from a business user or after detection of an upload

error, in which case an application manager user agreement is requested to avoid infinite refresh-upload loops.

o sends the freed motivated refresh request to the SIF.If an affiliation is found for the requested person, the SIF triggers a single update process when receiving the request and enlists it into the flux. If no affiliation is found for the requested person, the SIF denies the request by sending an empty career upload message with the RefreshRejectReason field set. In this last case, no loading report message is expected from the career DB application.



5.8.1.2 Sequence

5.8.2 VALIDATIONS

5.8.2.1 SIF sideThe validations are performed by the SIF application on the refresh request:

o The person is known and has been affiliated by the SIF, otherwise a RefreshRejectReason with a “NoAffiliation” value is provided by the SIF in response to the request.

o The SIF must accept the request If the SSIN provided by RSVZ is older than the SSIN currently known at the SIF side. In such cases, the PersonNewIdentification is also returned in the refresh response allowing the RSVZ to update its reference data.

o If the SIF cannot immediately handle the request, an single career upload is returned with a RefreshRejectReason set to “ProcessingDelayed”. The SIF will later (but as soon as possible) transmit the career data within another single or bulk career upload.



o Other reasons specific to the SIF can lead to refresh denial. These are still to be documented.

5.8.2.2 Career DB sideo Same validations as for the single upload (see 5.7.3).o It is also validated that the received SSIN is the same as the requested one in the refresh

request or that it is present in the old identification. If it is not, the loading is not performed and the report will notify an error with return code “NotAllowed” and reason code “IdentificationMismatch”.

o Receiving a response (single career upload message) with a RefreshRejectReason set to “ProcessingDelayed” will trigger a manual background timeout processing leading to a new refresh request when the timeout expires.

o If a refresh request is answered with a RefreshRejectReason set, the career DB application does not send the ReportCareerUpload message back.

5.8.2.3 Activity description



5.8.3 DATA

5.8.3.1 Operations

The operations involved in the single full career upload process are the following: RequestRefreshCareer, form RSVZ to SIF, UploadFullCareer, from SIF to RSVZ ReportCareerUpload, from RSVZ to SIF, invoked after validation and loading of the

received career

5.8.3.2 Data structures

The above operations are related to SOAP body literal messages which structure have the standard B2B layout, i.e.


[REF2]) Followed by the specific business structure here named

o “CareerRefreshRequestData” for the requesto “UploadCareerData” for the career data to loado “ReportData“ for the load report message

Are made of an “ApplHeader” structure for the POW response messages (see [REF2])

Except for CareerRefreshRequestData, the data structures are documented in the bulk scenario (see 5.5.7.2).

Figure 22: Career refresh request data structure



Figure 23: Upload on refresh request


Refresh request

Node Parent node Nbr Value restrictions Value to setRequestRefreshCareer Document 1ApplHeader RequestRefreshCareer 1Timestamp ApplHeader 1 Defined by par





“1202”




“1202”


Value unique to the message, chosen by the




Node Parent node Nbr Value restrictions Value to setPEN application

UserID ApplHeader 1 Chosen by PENRequestInitiatorID ApplHeader 0 Not used in current

contextFluxDescriptor RequestRefreshCareer 1Initiator FluxDescriptor 1Organization Initiator 1 3 alphanumeric



“1202”




characters“RefreshCareer”

Version FluxDefinition 1 Defined by xs:int 1CareerRefreshRequestData

RequestRefreshCareer 1

ReasonCode CareerRefreshRequestData

1 Value list1 Reason why refresh is requested

SSINType CareerRefreshRequestData


SSIN CareerRefreshRequestData


DeadlineDate CareerRefreshRequestData

1 Defined by xs :date Date until which a career upload is expected from the SIF

Upload data:

Node Parent node Nbr Value restrictions Value to setUploadFullCareer Document 1ApplHeader UploadFullCareer 1Timestamp ApplHeader 1 Defined by par





“1202”




“1202”



UserID ApplHeader 1 Chosen by the SIF

1 Possible values are : « InitialLoadError », « ReloadError », « PensionRequest », « EstimationRequest », « Other »



Node Parent node Nbr Value restrictions Value to setRequestInitiatorID ApplHeader 0 Not used in current

contextFluxDescriptor UploadFullCareer 1Initiator FluxDescriptor 1Organization Initiator 1 3 alphanumeric



“CareerDB”




characters“RefreshCareer”

Version FluxDefinition 1 Defined by xs:int 1UploadCareerData UploadFullCareer 1ChangeReason UploadCareerDat

a1 Value list “Requested”

RefreshRejectReason UploadCareerData

0..1 Value list1 Reason why refresh is rejected, if applicable

IndividualRights UploadCareerData

0..1 If refresh request is approved by SIF

CreationTime IndividualRights 1 Defined by xs:dateTime Time of career data creation

BeginValidityDate IndividualRights 1 Defined by xs:date Date from which provided career is valid

PersonIdentification IndividualRights 1 Person identificationLastName PersonIdentificati

on0..1 String


0..1 String





BirthDate PersonIdentification

0..1 Defined by xs :date


IndividualRights 0..1 Only if more recent info available at SIF side

Identification of person as known by the SIF if more recent


1 Mandatory in current context









1 List values still to be settled between partners



Node Parent node Nbr Value restrictions Value to setCareerDetail IndividualRights 1 ..

nCareer period detail

BeginYear CareerDetail 1 Value between 1956 and 2080

Period begin Year



Period end Year


PeriodKind CareerDetail 1 Value listIncome1 CareerDetail 0..1 AmountIncome2 CareerDetail 0..1 AmountCumulatedIncome CareerDetail 0..1 AmountTemporaryInd CareerDetail 0..1 Defined par xs :booleanReferenceYear CareerDetail 0..1 Value between 1900 and




UncondPen IndividualRights 0..1Amount UncondPen 1 Amount Unconditional pension


Amounts are provided in EUR and defined by xs:decimal restricted to max 10 digits and with 2 mandatory decimal digits.The report data values are the same as for the single upload (see 5.7.4.3) with the following exception:

o Flux Name = “RefreshCareer”



5.9 CAREER DOWNLOAD

5.9.1 PROCESS

The career data download is requested by the SIF in order to allow it knowing the exact state of the data stored within the career database for a specific person. The returned data will contain the current state or the historical information for that particular person depending on the request selection criteria,The process is supported by a request-reply (RR) exchange flowing through the B2B gateway.

5.9.1.1 Process detailsThe process is interactively started by a SIF user who submits a career status request to its application. The SIF system synchronously triggers a career download request that flows to the career database application through the B2B gateway. The gateway forwards the request without sending a response to the SIF application.When receiving the business request, the career DB application validates the request and accesses its database in order to get the requested data before sending any response to the SIF through the B2B gateway.There is no automatic retry from the SIF application in case of timeout, SystemFault or ValidationFault. In such situations, it is the responsibility of the SIF application user to retry his query.

5.9.1.2 Sequence



Figure 24: Career download sequence diagram


The following validations will be automatically performed by the career DB application:

- The SIF membership is validated by the Career DB application upon reception of career download as following: a. The SSIN must be known by the Career DB application either as the current person

identification or as a previously known identification.i. If the requested SSIN is not known at all, the requested is rejected with

ReturnCode = “UnknownPerson”ii. If the requested SSIN is not known as the current person identification, a

warning is provided with ReturnCode =”SSINChanged”.iii. If the requested SSIN is known but was never affiliated to the requesting SIF,

a warning is provided with ReturnCode =”NoAffiliation”.b. The provided period for filtering data must be valid: begin period info must precede

end period info. If not, the request is rejected with ErrorCode = “InvalidPeriod” and the returned person identification contains both the current and old identifications.

- If the person is known and was affiliated but if no data is found for the corresponding period, the request is rejected with ReturnCode = “NoData”. If history is requested, the “NoData” return code will not be produced if historical data can be found.



- In all other cases, the ReturnCode is set to “OK”.

- When returning historical data, the “IsLoaded” attribute is returned to false if the uploaded data had not been loaded at the eClipz side.

- If a schema validation error happens at the career application side when receiving an RequestCareerInfo request, a ValidationFault is returned to the B2B system that will consequently reply to the SIF with a SystemFault.

5.9.3 DATA

5.9.3.1 Operations

The operation involved in the career download process is the following: RequestCareerInfo, from SIF to RSVZ RequestCareerInfoResponse, from RSVZ to SIF.

5.9.3.2 Data structures

The above operation is related to SOAP body literal messages which structure have the standard B2B layout, i.e.

Start with the “ApplHeader” structure for the request messages (see [REF2]) Followed by the specific business structures here named

o “RequestCareerData” for the requesto “CareerData” for the response

Figure 25: RequestCareerData element structure



Figure 26: CareerInfo structure


For request message:

Node Parent node Nbr Value restrictions Value to setRequestCareerInfo Document 1ApplHeader RequestCareerInfo 1




Node Parent node Nbr Value restrictions Value to setTimestamp ApplHeader 1 Defined by par





Specific to SIF




“1202”



UserID ApplHeader 1 Chosen by the SIFRequestInitiatorID ApplHeader 0 Chosen by the SIFRequestCareerData RequestCareerInfo 1ReadCriteria RequestCareerData 1HistoryInd ReadCriteria 0..1 Defined by xs:boolean True if history requestedPersonIdentification ReadCriteria 1LastName PersonIdentification 0..1 StringFirstName PersonIdentification 0..1 StringSSINType PersonIdentification 1 « NN » or « BIS » Type of SSINSSIN PersonIdentification 1 11 digits String SSIN identifying subject

personBirthDate Person 0..1 Defined by xs :datePeriod RequestCareerData 0..1 See FDSBeginYear Period 1 Value between 1900 et

2080Period begin Year

BeginQuarter Period 0..1 « Q1 » to « Q4 » Period begin quarter, Q1 assumed if not set

EndYear Period 1 Value between 1900 et 2080

Period end Year

EndQuarter Period 0..1 « Q1 » to « Q4 » Period end quarterQ4 assumed if not set

For response message:

Node Parent node Nbr Value restrictions Value to setRequestCareerInfoResponse

Document 1

ApplHeader RequestCareerInfoResponse

1





Application Origin 1 String (max 11 “1202”



Node Parent node Nbr Value restrictions Value to setcharacters)




Specific to SIF


Value unique to the message, chosen by the career DB aplication

UserID ApplHeader 1 Chosen by the the career DB aplication

RequestInitiatorID ApplHeader 0 Not used in current context

CareerData RequestCareerInfoResponse

1

ReturnCode CareerData 1 Restricted listCurrentCareer CareerData 0..1 Mandatory if no error Current data as

communicated by the SIFCreationTime CurrentCareer 1 Defined by xs :dateTime Date and time of creation BeginValidityDate CurrentCareer 1 Defined by xs :date Data validity begin datePersonIdentification CurrentCareer 1 Identification as

requested by the SIFLastName PersonIdentification 0..1 StringFirstName PersonIdentification 0..1 StringSSINType PersonIdentification 1 « NN » or « BIS » Type of SSINSSIN PersonIdentification 1 11 digits String SSIN identifying subject

personBirthDate PersonIdentification 0..1 Defined by xs :datePersonNewIdentification

CurrentCareer 0..1 Identification as known by RSVZ if more recent










0..1 Defined by xs :date Mandatory in current context

CareerDetail CurrentCareer 1..n See CareerDetailStruct in WSDL

Last Career detail communicated by SIF

UncondPen CurrentCareer 0..1 See UncondPenStruct in WSDL

Unconditional pension rights communicated by SIF

CareerHistory CareerData 0..n History of changes if requested

IsLoaded CareerHistory 0..1 Boolean attribute Defaults to trueChangeReason CareerHistory 1 Value list Reason provided by the

SIF to the following



Node Parent node Nbr Value restrictions Value to setupdate

TimeReceived CareerHistory 1 Defined by xs :dateTime Time change processed at RSVZ-INASTI

TimeReplaced CareerHistory 0..1 Defined by xs :dateTime Time change replaced by another one at RSVZ-INASTI

ChangeExceptionReason

CareerHistory 0..1 Reason why change got an exception

IndividualRights CareerHistory 1 Career data as communicated by the SIF

CreationTime IndividualRights 1 Defined by xs :dateTime Date and time of creation BeginValidityDate IndividualRights 1 Defined by xs :date Data validity begin datePersonIdentification IndividualRights 1 Old identification if

communicated by SIFLastName Person 0..1 StringFirstName Person 0..1 StringSSINType Person 1 « NN » or « BIS » Type of SSINSSIN Person 1 11 digits String SSIN identifying subject

personBirthDate Person 0..1 Defined by xs :dateIdentification SubjectPerson 1 Identification data

communicated by the SIFLastName Person 0..1 StringFirstName Person 0..1 StringSSINType Person 1 « NN » or « BIS » Type of SSINSSIN Person 1 11 digits String SSIN identifying subject

personBirthDate Person 0..1 Defined by xs :dateCareerDetail IndividualRights 1..n See CareerDetailStruct

in WSDLCareer detail communicated by SIF

UncondPen IndividualRights 0..1 See UncondPenStruct in WSDL

Unconditional pension rights communicated by SIF



5.10 BUSINESS SIGNALS

5.10.1 PROCESSBusiness signals are notification flows initiated by RSVZ under some specific circumstances. These may be related to refresh requests but do not share their “flux”.Signals are triggered by the three following causes :

Pension request Pension estimation request 74L

Signals flow through the B2 gateway.

5.10.1.1Process details

The signal is triggered by the PEN application, formatted into a notification message and transmitted to the SIF through the B2B gateway using a POW exchange pattern. No business response is expected from the SIF.

Only SIFs subscribing to the signal service will receive non-74L notifications. All SIFs will receive 74L notifications.

The SIF must handle the non-74L signals at technical level by sending a response back to the B2B gateway, but the SIF is free to handle it at functional level or not.

The signal processing at the SIF must be idempotent in that the SIF must accept multiple identical signals at technical level (same MessageID) or at functional level (same business content) without generating an error response and without disturbing its internal processes.

The SIF should retain the last signal business information if it receives multiple functionally distinct signals for the same person.

The B2B gateway application manager must contact the career DB application manager if a signal message cannot be delivered to the target SIF for any reason.

The career DB application sends a signal notification to all SIFs having a registration for the considered subject person.



5.10.2 SEQUENCE

The normal sequence of operations is described by the following sequence diagram:

Figure 27: Application level signal notification sequence

The sequence of operations at transport level is described in the following sequence diagram:

Figure 28: Low level signal notification sequence

5.10.3 VALIDATIONValidation at SIF side is discretionary to SIF constraints and is not within the scope of this document.

5.10.4 DATA

5.10.4.1Operations

The operation involved in the notification process is the following:



SignalChange, from RSVZ to SIF

5.10.4.2Data structures

The above operation is related to a SOAP body literal message which structure has the standard B2B layout, i.e.

Start with the “ApplHeader” structure (see [REF2]) Followed by the “ChangeData” specific business structure that conveys notification data

depending on the signal type.



Figure 29: ChangeData structure



Figure 30: Pension request signal structure



Figure 31: 74L signal structure



Figure 32: 74L response signal structure

5.10.4.3Data values1

5.10.4.3.1 Signal requests

Node Parent node Nbr Value restrictions Value to setSignalChange Document 1




Node Parent node Nbr Value restrictions Value to setApplHeader SignalChange 1Timestamp ApplHeader 1 Defined by xs:dateTime Date and time of

message creationOrigin ApplHeader 1Organization Origin 1 3 alphanumeric



“1202”


charactersSIF code (ex “003”)


“1202”


Value unique to the message, chosen by RSVZ/INASTI

UserID ApplHeader 1 RSVZ user managing the pension computation

RequestInitiatorID ApplHeader 0 Not usedChangeData SignalChange 1SignalKind ChangeData 1 EnumerationBeneficiaryPerson ChangeData 1 Person who is

introducing the demand to benefit from pension rights

LastName BeneficiaryPerson 0..1 StringFirstName BeneficiaryPerson 0..1 StringSSINType BeneficiaryPerson 1 « NN » or « BIS » Type of SSINSSIN BeneficiaryPerson 1 11 digits String SSIN identifying

beneficiary personBirthDate BeneficiaryPerson 0..1 Defined by xs :dateCareerDBInfo SignalChange 1CreationDate CareerDBInfo 1 Defined by xs:date Date when SIF

communicated changes to RSVZ-INASTI

LastUpdateDate CareerDBInfo 0..1 Defined by xs:date Date as known by RSVZ when the SIF last updated data for that person

LastUpdateUser CareerDBInfo 0..1 String Identification as known by RSVZ of SIF user who last updated data for that person

Pension estimation signal : Nothing morePension request signal :PensionRequest ChangeData 1PensionInfo PensionRequest 1..n Pension parameters for

- Retirement and optionally :

- Survival or divorced



Node Parent node Nbr Value restrictions Value to setpension from one or more heads

PensionKind PensionInfo 1 Value list Retirement or survival/divorced

HeadSSINKind PensionInfo 0..1 Value list Kind of SSIN for person from which rights are inherited (for survival/divorced pension kind)

HeadSSIN PensionInfo 0..1 SSIN of person from which rights are inherited (for survival/divorced pension kind)

PensionBeginDate PensionInfo 1 Defined by xs :date Pension start date74L signal :Request74L ChangeData 1RequestID Request74L 1 Up to 36 alphanumeric

charactersUnique identification of 74L request set by RSVZ and used to correlate with potential responses-

PensionKind Request74L 1 Value list Retirement or survival/divorced

PensionBeginDate Request74L 1 Defined by xs :date Pension start dateIsFamilyRateApplied Request74L 0..1 xs :boolean True if the pension is

granted at family rate, false for single right, absent if not applicable.

Activities Request74L 1 List of professional activities run by the beneficiary or his/her spouse

Activity Activities 1..n One activity definitionIsForSpouse Activity 0..1 Attribute - xs :boolean True if activity is for

spouse, false or absent for beneficiary

PensionBeginDate Activity 1 Defined by xs :date Pension Begin start date of activity

ActivityKind Activity 1 Value list Kind of activity performed by target person

SpouseIdentification Request74L 0..1 Provided if family rate applied

LastName SpouseIdentification

0..1 xs :string Spouse last name

FirstName SpouseIdentification

0..1 xs :string Spouse first name

SSINType SpouseIdentification

1 Value list Kind of SSIN for spouse

SSIN SpouseIdentificatio 1 11 digits String SSIN of spouse



Node Parent node Nbr Value restrictions Value to setn

BirthDate SpouseIdentification

0..1 xs :date Spouse birth date

5.10.4.3.2 Signal responses

Node Parent node Nbr Value restrictions Value to setSignalChange Document 1ApplHeader SignalChange 1Timestamp ApplHeader 1 Defined by xs:dateTime Date and time of

message creationOrigin ApplHeader 1Organization Origin 1 3 alphanumeric

charactersSIF code


“1202”


charactersRSVZ/INASTI : « 000 »


“1202”



UserID ApplHeader 1 SIF used code RequestInitiatorID ApplHeader 0 Not usedChangeData SignalChange 1SignalKind ChangeData 1 Enumeration “S74L”BeneficiaryPerson ChangeData 1 Person who is

introducing the demand to benefit from pension rights

LastName BeneficiaryPerson 0..1 StringFirstName BeneficiaryPerson 0..1 StringSSINType BeneficiaryPerson 1 « NN » or « BIS » Type of SSINSSIN BeneficiaryPerson 1 11 digits String SSIN identifying

beneficiary personBirthDate BeneficiaryPerson 0..1 Defined by xs :dateCareerDBInfo SignalChange 0 Not used in current

context74L response signal :Response74L ChangeData 1RequestID Request74L 1 Up to 36 alphanumeric

charactersUnique identification of 74L request set by RSVZ and used to correlate with potential responses-

PensionKind Request74L 1 Value list Retirement or survival/divorced

IsFamilyRateApplied Request74L 0..1 xs :boolean True if the pension is



Node Parent node Nbr Value restrictions Value to setgranted at family rate, false for single right, absent if not applicable.

Activities Request74L 1 List of professional activities run by the beneficiary or his/her spouse

Activity Activities 1..n One activity definitionIsForSpouse Activity 0..1 Attribute - xs :boolean True if activity is for

spouse, false or absent for beneficiary

PensionBeginDate Activity 1 Defined by xs :date Pension startBegin date of activity

EndDate Activity 0..1 Defined by xs :date End date of activityActivityKind Activity 1 Value list Kind of activity

performed by target person

EndAgreementReason

Activity 0..1 xs :string Reason why the ending was detected and agreed

SpouseIdentification Request74L 0..1 Provided if family rate applied

LastName SpouseIdentification

0..1 xs :string Spouse last name

FirstName SpouseIdentification

0..1 xs :string Spouse first name

SSINType SpouseIdentification

1 Value list Kind of SSIN for spouse

SSIN SpouseIdentification

1 11 digits String SSIN of spouse

BirthDate SpouseIdentification

0..1 xs :date Spouse birth date



6. INFLUENCE ON OTHER SYSTEMS AND PROCESSES

After the initial load, the sending by PEN of new electronic 2B requests should be stopped for the already loaded careers, but ongoing 2B request should still be acknowledged and answered as well as for careers that were not loaded yet.



7. APPENDIXES

7.1 SCHEMAS

7.2 WSDLThe XML schemas and WSDL provided below are for documentation purposes only. Please refer to the actual XSD and WSDL files to implement your services. XML schemas

7.3 FORMULAS AND VALUES

7.3.1 UPLOAD REJECTION THRESHOLD

T = C * 0,05Where

T = Threshold above which rejection happens – unit = number of careersC = Total number of uploaded careers - unit = number of careers

Taking error severity into account:

S = 1C Si

Where Si = severity of error for Career element i (Si = 0 if OK, Si = 1 for error, Si = 0,5 for warning)S = total severity

Full rejection happens when S > T

7.3.2 TIMEOUTS AND DELAYSTimeout and delays are time intervals used to monitor ongoing processes either on the SIF or B2B or PEN sides of the data exchanges. Their value will depend on the involved party and from SIF to SIF.

7.3.2.1 T1T1 is the timeout that is triggered by the SIF application when no business report is received within delays when processing a single full career upload.The value is computed in minutes since the Report is sent by the receiver application after asynchronous processing of the input request.

Typical value: 5 minutes.

7.3.2.2 T2T2 is the timeout that is triggered by the transport software on the SIF or PEN or B2B platform when no Response nor fault is received within delays when processing a Pseudo One Way request.The value is computed in seconds since the Response message is sent by the receiver transport layer immediately after having passed the request message to the target application.

Typical value: 30 seconds.Current value for T2 in eCLipz implementation: 60 seconds.



7.3.2.3 T3T3 is the interval after which a Pseudo One Way request is repeated by the sender transport software after a timeout or a SystemFault.The value is computed in minutes in order to let the server or network enough time to recover.The value of T3 could start with a given value and increase depending on the retry number.Typical value: 5 minutes.

7.3.2.4 T4T4 is the value of the timeout that is triggered by a calling system in a REQUEST-REPLY pattern when no reply has been received within delays.T4 is computed in seconds since RR patterns require low latency.

T4 is smaller at the B2B level than it should be at the initial caller level in order to take the network and B2B latency.

Typical value: 30 seconds

7.3.2.5 T5T5 is the interval after which a REQUEST-REPLY request is repeated by the sender application after the previous one went into timeout.The value is computed in minutes in order to let the server enough time to recover.


7.3.2.6 T6

T6 is the time interval after which a Bulk upload is considered as incomplete by the receiving party if not all messages were received within that delay.The value is computed in minutes and should be large enough to allow all chunks to be received.


7.3.2.7 T7Bulk upload Load Report timeout on the sender side (after receiving the acknowledgement).


7.3.2.8 T8T8 is the interval after which a refresh request is repeated by the career db application after the previous one went into timeout (no career data received).

1 Reduce xml prefixes sizes to 2 digits to limit message sizes2 Estimation of encrypted size plus encryption delay and load delay still to be done3 Value of timeouts to be agreed4 Maximum number of retries to be agreed5 Score computation should be defined6 ApplHeader Destination and Origin : PEN = RSVZ = 000 ??? or is there a specific value for PEN7 ApplHeader Destination and Origin : PEN = RSVZ = 000 ??? or is there a specific value for PEN8 Value of timeouts to be agreed9 Maximum number of retries to be agreed10 ApplHeader Destination and Origin : PEN = RSVZ = 000 ??? or is there a specific value for PEN11 ApplHeader Destination and Origin : PEN = RSVZ = 000 ??? or is there a specific value for PENAll values for CareerChangeReasonType12 ApplHeader Destination and Origin : PEN = RSVZ = 000 ??? or is there a specific value for PENAll values for CareerChangeReasonType



The value is computed in days in order to let the SIF enough time to collect the data. A refresh request linked to a pension request has however a higher priority than for an estimation request. The timeout can be inferred by the SIF from the refresh request (DeadlineDate).

Typical values: 30 days.Current value for T8 in eCLipz implementation: 10 days.

7.3.2.9 T9

Bulk upload Acknowledgement timeout on the SIF side after all chunks were sent and got their technical acknowledgement.




NOTES - QUESTIONS


career database exchanges specifications - nisse | … · web viewif a pow request message does not...

Documents