<![CDATA[poor beggar - John Claes - Made By John Claes]]>Fri, 13 Mar 2026 10:36:52 +0100Weebly<![CDATA[Group S : Onboarding]]>Sun, 28 Sep 2025 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/group-s-onboarding
]]><![CDATA[Riziv / Inami : ContactViews]]>Thu, 11 Sep 2025 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/5226419

Context

When Migration from Contact Contexts are being analyzed we get every time the same questions.
  • Contact => Legal Context => Atlas 
  • MedCons => MedCons Context => MedCons 

Target

When Migrating a project towards Atlas we loose the other contexts. When we need that data we need to think about this matrix  
Use this matrix to decide whether to plan an Api Migration  or use the “Materialized View Pattern” option of the “Operation Data Integration“ decision
ct_2025_09_12_contactviews.pptx
File Size: 457 kb
File Type: pptx
Download File
]]><![CDATA[Riziv / Inami : StatusFlows]]>Thu, 11 Sep 2025 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-statusflows

Context

When analyzing the migration of Projects that use Appian / Windows WorkFlow Foundation we decided already that for WorkFlows we'll use Elsa. 
On the otherside we notice that "For WorkFlows" is not a clear identification / Attribute of projects. 
We created this Matrix to check on a Neutral way the Need of WorkFlows in the project. 

Target

Use this matrix to decide whether to implement a status flow as code (Process Flow) or using a workflow engine like Elsa.
ct_2025_09_12_statusflows.pptx
File Size: 480 kb
File Type: pptx
Download File
]]><![CDATA[Riziv / Inami : interproject communication]]>Thu, 11 Sep 2025 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-interproject-communication

interproject-communication

]]><![CDATA[Riziv / Inami : Automated Testing]]>Wed, 03 Sep 2025 12:24:46 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-automated-testing

Automated UI Testing : Playright vs Selenium

  • OK for playright
  • OK for playright as default
  • OK for selenium support ( Existing Seleniums don't have to change ) 

we need to check with Platform to make sure that the Deploys are not to slow.

As we've decided in ADR202311-006 that we're pushing on more tests, we have the request from annalists and Testers to be able to add Automated UI tests. 
CT Analyse is working on this and need us to decide which option we'll be supporting.


We've 2 POC projects that use each a different option so we've made now a decision chart to assist in this Discussion. 
The PPS and demo material will be linked here when available. 

An option is always that we support both, but no other .... 
e2e.rar
File Size: 39 kb
File Type: rar
Download File
e2e_test_automation_2.pdf
File Size: 1736 kb
File Type: pdf
Download File
]]><![CDATA[Riziv / Inami : StructCom]]>Mon, 11 Aug 2025 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-structcom

StructCom

Transversal tool to create Structural Communications 
  • Payments ( this is the only way to keep them unique over projects ) 
  • Invoices ( Bel and EU ISO are added ) 
]]><![CDATA[Riziv / Inami : Nihdi.Common.Validators]]>Tue, 01 Apr 2025 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-nihdicommonvalidators

Nihdi.Common.Validators.Iban

Introduction
This project contains a Common Iban Validator. this Validator can be used to create a Iban object that will return a true/False response on the CheckIfValid Question.
Getting Started
  1. Reference this Nugget
  2. Create a Iban instance ( Constructor needs the number to check )
  3. Use the Method CheckIfValid to check if it's a valid Iban.
Important to know: This Iban validator is checking the Modulus for all covered countries.
Build and Test
Iban iban = new("NotValid");
iban.CheckIfValid();
Contribute
​for support or bugs : please contact John Claes with the test case so we can add the case to our tests and fix the bug.
Nugget Feed PRD: 

Nugget Feed DEV : 
https://tfs.riziv.org/tfs/DefaultCollection/Common/_artifacts/feed/Riziv2-PreRelease/NuGet/Nihdi.Common.Validators.IbanValidator 

Nihdi.Common.Validators.CBSS

Introduction
​This project contains a Common CBSS Validator. this Validator can be used to create a CBSS object that will return a true/False response on the CheckIfValid Question.
Getting Started
  1. Reference this Nugget
  2. Create a CBSS instance (Constructor needs the number to check)
  3. Use the Method CheckIfValid to check if it's a valid CBSS number
Important to know:
  1. CheckIfValid needs a true/false indication if you want to make sure it's may be a Biss number
    1. current implementation checks belgian niss and Biss numbers
    2. default we allow bis numbers
  2. even when the imput is wrong, it can be that you get a true: check the string value for the "Corrected" value.
Build and Test
Niss niss = new Niss("NotValid");
niss.CheckIfValid();
niss.CheckIfValid(true);
niss.CheckIfValid(false);
Contribute
​for support or bugs : please contact John Claes with the test case so we can add the case to our tests and fix the bug.
Nugget Feed PRD: 

Nugget Feed DEV : 
https://tfs.riziv.org/tfs/DefaultCollection/Common/_artifacts/feed/Riziv2-PreRelease/NuGet/Nihdi.Common.Validators.CBSSValidator 

Nihdi.Common.Validators.CBE

Introduction
This project contains a Common CBE Validator. this Validator can be used to create a CBE object that will return a true/False response on the CheckIfValid Question.
Getting Started
  1. Reference this Nugget
  2. Create a CBE instance (Constructor needs the number to check)
  3. Use the Method CheckIfValid to check if it's a valid CBE number
Important to know:
  1. CheckIfValid needs a true/false indication if you want to make sure it's a Belgian CBE
    1. current implementation only checks Belgian numbers
  2. even when the imput is wrong, it can be that you get a true: check the string value for the "Corrected" value.
Build and Test
Cbe cbe = new("NotValid");
Assert.IsFalse(cbe.CheckIfValid(true));
Contribute
​for support or bugs : please contact John Claes with the test case so we can add the case to our tests and fix the bug.Nugget Feed PRD: 

Nugget Feed DEV : 
https://tfs.riziv.org/tfs/DefaultCollection/Common/_artifacts/feed/Riziv2-PreRelease/NuGet/Nihdi.Common.Validators.CBEValidator

Nihdi.Common.Validators.NihdiNumber

Introduction
This project contains a Common NihdiNumber Validator. this Validator can be used to create a NihdiNumber object that will return a true/False response on the CheckIfValid Question.
Getting Started
  1. Reference this Nugget
  2. Create a NihdiNumber instance ( Constructor needs the number to check )
  3. Use the Method CheckIfValid to check if it's a valid NihdiNumber.
Important to know:
This NihdiNumber validator is checking for the current and old checks ( 97-89-83 and 79 ) even when the imput is wrong, it can be that you get a true: check the string value for the "Corrected" value.
Build and Test
NihdiNumber nihdiNumber = new NihdiNumber("NotValid");
nihdiNumber.CheckIfValid()
Contribute
for support or bugs : please contact John Claes with the test case so we can add the case to our tests and fix the bug.
Nugget Feed PRD: 

Nugget Feed DEV : 
https://tfs.riziv.org/tfs/DefaultCollection/Common/_artifacts/feed/Riziv2-PreRelease/NuGet/Nihdi.Common.Validators.NihdiNumberValidator 

Nihdi.Common.Validators.Mail

Introduction
This project is not implemented as the System.Net.Mail has a very good validation when trying the Constructor.
Getting Started
  • Reference the namespace : System.Net.Mail
using System.Net.Mail;
  • ​Use the Constructor of MailAddress or the static TryCreate(string? address, out System.Net.Mail.MailAddress? result);
public class MailAddress

​​public static bool TryCreate(string? address, out System.Net.Mail.MailAddress? result);
  • Handle the Thrown errors as they are Validation errors when using the constructor
Important to know:
  1. MailAddress is a System.Net.Mail Class with a well documented and valid validation of mail MailAddresses
Build and Test
​1. Constructor
public static bool ValidateMailAddress(string mailAddressToCheck)
{
      try
      {
            MailAddress ma = new(mailAddressToCheck);
            return true;
      }
      catch
      {
            // if you want to know the real error also.
            // please catch the error and log / return the message.
            return false;
      }
}
2. TryCreate
public static bool ValidateMailAddress(string mailAddressToCheck)
{
      ​return MailAddress.TryCreate(mailAddressToCheck, out MailAddress? ma );
}
Contribute
for support or bugs : please contact John Claes with the test case so we can add the case to our tests
]]><![CDATA[Riziv / Inami : Proposition Deployment Flow :]]>Thu, 06 Mar 2025 23:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-proposition-deployment-flowARB - InfraReq - IRB - Release - Deploy

a schematically drawn proposition of the Deployment Flow for all projects 

Proposition
  • was checked 07 March 
  • accepted : check pdf 
Records 
voorstel_deployment_flow_0.0.0.pdf
File Size: 96 kb
File Type: pdf
Download File
voorstel_deployment_flow_0.0.1.pdf
File Size: 96 kb
File Type: pdf
Download File
voorstel_deployment_flow_0.0.2.pdf
File Size: 75 kb
File Type: pdf
Download File
]]><![CDATA[Riziv / Inami : Blazor reusable components]]>Thu, 09 Jan 2025 23:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-blazor-reusable-components

Blazor reusable components

a Nugget that mixes the Microsoft Blazor version together with the DesignSystem . 
Instead of forcing the Developers to follow the designSystem with every change, we can make their life easier with providing this nugget, that makes sure that the designsystem overwritten Items are correctly implemented and with a Nugget refresh, changes will be shown. 

This is a long Running initiative with multiple TL's working on it 
]]><![CDATA[Riziv / Inami : Project DashBoard]]>Sun, 05 Jan 2025 23:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-project-dashboard

Trying to get everyone to use the same dashboard

  • Architectural milestones
  • Staff milestones 
  • Migration milestones 

]]><![CDATA[Riziv / Inami : eDocFlow - Structure]]>Sun, 05 Jan 2025 23:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-edocflow-structure

Setting up a messagebus choreo for eDocFlow

eDocFlow is the Electronic Document application for communication with external Destinations. 
  • Enable document communication (inbound and outbound) between an application and a recipient (internal or external)
  • Offer services such as:
    • Document generation and transmission based on a template
    • adding a signature (image signature or electronic signature) to a document
    • Transmission of the document to the centralized storage service (eDocCenter).
The outbound process is the process where documents are sent from RIZIV-INAMI.
The process starts in applications or Sharepoints where documents, or information is available for sending.
eDocFlow receives the information, creates the necessary IDs to follow the lifecycle of the document, and based on the metadata, decides where the document should be delivered.
Outgoing documents are sent to our partners (bpost, EasyPost, my e-box, EboxEnterprise, eHealthBox).
The types of outgoing documents (generated by Windward or free format) are:
  • Normal sending of document
  • Registered mail (with proof of receipt by the receiver)
  • Managing documents long term (normal archiving and retention)
  • Sending documents via email
  • Electronic transfer of document to e-box citizens / e-health box.
Law on eBox 
​The law of 15 August 2015 on the incorporation and organisation of a federal service integrator organized the communication and integration of data from different data sources and promoted data single collection, central registration and access. The eBox law of 28 February 2019 stipulated the provisions concerning eBox, an electronic mailbox that can be used by public actors to exchange electronic communications with Belgian citizens and registered companies and organisations, including registered mail. The Royal Decree of 2 June 2019 stipulated the conditions for private service providers to be accredited to make available the eBox to citizens.
Picture
]]><![CDATA[RIZIV / INAMI : Medical Advisor]]>Thu, 28 Nov 2024 23:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-medical-advisor

Other Names

  • MedCons  : Old Aplication Name
  • Stands for : médecin-conseil  / medisch adviseur​

Overview

  • Change In Scope:
    • From View and Context in Contact
    • To Api and Local Storage of needed data
    • .NetMigration
      • .Net 8
      • WebApi
      • NamingConvention
  • Change Out Of Scope
    • Contact DataDistribution
Picture
Picture
]]><![CDATA[Riziv / Inami : Operational Data Integration]]>Thu, 28 Nov 2024 23:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-operational-data-integration
Work File : DataDistributionOptions.xlsx
Part 1 : options : CT_2024_11_29_DataDistribution 1.pptx
File 2 : CT_2025_03_07_Operational Data Integration_Part2.pptx
File 3: CT_2025_05_19_Operational Data Integration_Part3.pptx

We decided that following propositions are selected to go further on following 3 propositions

  • High count Records
    • Enterprise bus
    • Cross DB Bulk Queries ( materialized Indexed Views ) on Replicated Databases
  • Low Count Records
    • Redis Cache 
ct_2024_11_29_operational_data_integration.pptx
File Size: 595 kb
File Type: pptx
Download File

Decision matrix : when to use which option 

Part 2 : CT_2025_03_07_Operational Data Integration_Part2 
  1. Matrix is Accepted
    1. Materialized View : ServiceBus : ( Who will create Initial Package and setup ) 
      1. John will check what is possible here with ok from Arnaud
    2. Replicated DB :
      1. I&O are using Azure SQL DB so this option is not on the table with current Choices 
    3. Caching : Wilke will make a study if Redis ( that is used in Community version ) is the right match as this eliminates the 2 best Caching options ( Read-through and refresh-ahead  ) => Arnaud has given the Pragmatic Go
ct_2025_02_xx_operational_data_integration_part2_version2.pptx
File Size: 485 kb
File Type: pptx
Download File

Part 3 2025_05 

Decided: 
  1. Materialized View : ServiceBus : ( Who will create Initial Package and setup ) 
    1. John will check what is possible here with ok from Arnaud
  2. Caching : Wilke will make a study if Redis ( that is used in Community version ) is the right match as this eliminates the 2 best Caching options ( Read-through and refresh-ahead  ) => Arnaud has given the Pragmatic Go
ct_2025_05_xx_operational_data_integration_part3.pptx
File Size: 635 kb
File Type: pptx
Download File

Discussion was made around the 4 options on how we will communicate the Mutations ( Page 7 ) 

  1. Minimalistic : This was clearly a noGO 
  2. Pragmatic : Chosen for All GDPR data Mutations
  3. Mutated Data : Chosen for second best and can be used for Non GDPR data mutations
  4. Full Data : This was clearly a noGO 

Next step : 

  • John will create Nihdi.Common.Integrations.Mutations Contract examples 
  • John will check examples with Gabriel of Contact / Atlas to have real feedback 
  • Wilke will Document the Redis naming conventions ( we notice that RefData is already stored multiple times ... ) 
]]><![CDATA[RIZIV / INAMI : Colindos]]>Thu, 07 Nov 2024 23:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-colindos9011943Change upon: ADR-2024-09

Overview

  • For the Collège des Médicins-Directeurs (CMD) - College van Artsen-Directeurs (CAD) there is currently no specialized application.
  • The current management of the data is still done by using Excel and Access.
    • These applications no longer meet the current standards regarding the treatment of patient data.
    • Furthermore, these applications do not form a "seamless" whole which negatively affects efficiency and productivity.
  • We stay in the loop to ensure correct use of Concerto and the existing functionalities and security setup
Picture

Requirements

  • User needs to create a Questionnaire
  • Questionnaire Notification should be by mail ( notif, no data/File )
  • Questionnaire response needs to return PDF
  • Responses should be combined for College ( Concerto )
  • College Response should be retrieved and Stored

External Requirements

  • User : OA or health care provider : KSZ or eHEalth login ( 2 parts – Same functions – but we need eHealth added Claims -> 2 deploys : 2 ISP’s)
  • Questionnaire : List of QuestionTypes : Local
  • Storeage : Local
  • Notification Mail : SMTP ( is just link and Questionnaire name )
  • Response Pdf : Aspose directly as template is created during Questionnaire creation
  • Concerto Link Out-Of-Scope for MVP ( see rework Concerto )
  • Concerto input and response will be manual for MVP

Changes

Picture
Picture
]]><![CDATA[RIZIV / INAMI : Established Rights]]>Thu, 07 Nov 2024 23:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-established-rights4958342Changes upon: ADR 2024-09

Other Names

  • VastgesteldRecht
  • Droits Constatés

ambiguous language

  • Ordiges ( Finance supplier )
  • Ask&Go : Acceptance application from Ordiges that sends accepted rights / Payments to PIA
  • PIA : Finance application from Ordiges

Overview

  • API between business applications and Ordiges ( Finance )
    • We deliver the Rights to Ask&Go ( Ordiges – Acceptance Part )
    • We check the status ( ask&Go and PIA )
    • We store the Benificiares in PIA ( FinFiscData will be linked to PIA ) 

InScope

  • API (OutgoingRights / Benifs )
    • Validation
  • Internal bus
    • retries
  • Client Package
    • Use of both API’s
  • External bus
    • API requests
  • Migration
    • HangFire Jobs handler
  • MyPortal-FrontEnd
    • FinFiscData_FO ( using Benifs-API )
    • FinFiscData_BO ( using Benifs-API )
  • FileShare
    • Migration
    • Backup / debugging
  • FrontEnd
    • Dashboard

OutScope

  • API (Incomming right )
    • Validation

Changes

  • Add DB
    • Ordiges can’t store the following Links per paydomain
      • Benificiary and Fiscal Responible
      • Benificiary and BankAccountNumber per
    • This has impact on Benif-API
      • Has to store in or load from Ordiges and DB

Possible changes

We’re looking into a possible BankAccountNumber issue with Ordiges Api’s
Picture
Picture
Picture
]]><![CDATA[RIZIV / INAMI : GMCI - Angular Update]]>Sun, 06 Oct 2024 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-gmci-angular-update

Overview

  • Request for an Extra BackOffice Deploy Unit
    • We keep the current Unit
    • We ask for a second deployable environment in TST for our Angular tests
  • Important
    • Temporary : Just for testing the update and migration changes
    • Change is in the Deployment pipeline
      • Platform is creating a Third Build Server version with the newest Node version ( Only 1 is supported )
      • Deployment Pipeline will be the differentiator to know on which instance the deploy will occur
  • What is changing
    • Nothing Structural
    • The InfraReq Changes for the duration of the Tests 
Picture
]]><![CDATA[RIZIV / INAMI : Wasp Interface - Part Of IOC]]>Sun, 06 Oct 2024 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-wasp-interface-part-of-ioc

Overview

  • Why Printing Solution (Wasp - Xerox printing)
    • This is an application developed by Xerox to prepare the printing of the letters to be sent.
      • It groups the letters and add the barcodes needed by bPost and send status to the message broker.
  • Needs of change for Printing Solution (Wasp - Xerox printing)
    • The three environments (TST, VAL, PROD) send the documents to be printed to the production printers (we don’t have any other printers)
    • Even if the printing jobs are prefixed with de environment (i.e PRD_20240919_.... or TEST_20240919_...) the operator mistakenly print TEST or VAL letters and send it.  Creating sometimes problems for NIHDI.
    • To avoid this situation, the TEST and VAL documents will be sent to a shared folder and not anymore to the production printers.
what is changing
  • The printing jobs will be sent to a shared folder instead of being sent to the production printers
  • ​This is by adding a ShareFolder option in the destination List ( Printer1, Printer2, …. )
    • Wasp will send the documents at that moment to the sharedFolder instead of the printerQueue
Picture
]]><![CDATA[RIZIV / INAMI : eHealthBox - Part Of IOC]]>Thu, 05 Sep 2024 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-ehealthbox-part-of-ioc

eHealthBox is een Delivery Connector van IOC 

Overview

  • Change in the Connector ehealth box OUT
    • Remove the existing middleware
    • Better control of the communication with eHealth
      (the middleware doesn’t give a relevant feedback)
    • Increase the throughput to be able to send 1.000.000 messages in 24h
    • Cost reduction : we stop to pay for the middleware
  • Needs of the Connector ehealth box OUT
    • The existing communication software’s with eHealth box
      (eHealth connect unified messaging) d
      on’t have the capacity of sending 1.000.000 messages in 24h
      (Nihdi is the only entity that has such needs)
  • Architectural setup of a Connector ehealth box OUT
    • This is integrated in the existing component eHealthbox out saga  in the gateway.
    • No change in Deployeable components
  • What is changing
    • The component  eHealthbox out sent the message to the middleware (on prem) healthconnect UM and the middleware send the request to eHealth
    • Now the component will send the request directly to eHealth. ( Change Url )
    • We need a specific certificate (to avoid confusion in case of incident) to communicate with eHealth.
    • The InfraReq Changes 
]]><![CDATA[RIZIV / INAMI : Colindos]]>Thu, 05 Sep 2024 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-colindos

Overview

  • For the Collège des Médicins-Directeurs (CMD) - College van Artsen-Directeurs (CAD) there is currently no specialized application.
  • The current management of the data is still done by using Excel and Access.
    • These applications no longer meet the current standards regarding the treatment of patient data.
    • Furthermore, these applications do not form a "seamless" whole which negatively affects efficiency and productivity. 
Picture

Requirements

  • User needs to create a Questionnaire
  • Questionnaire Notification should be by mail ( notif, no data/File )
  • Questionnaire response needs to return PDF
  • Responses should be combined for College ( Concerto )
  • College Response should be retrieved and Stored

External Requirements

  • User : OA or health care provider : KSZ or eHEalth login ( 2 parts – Same functions – but we need eHealth added Claims -> 2 deploys : 2 ISP’s)
  • Questionnaire : List of QuestionTypes : Local
  • Storeage : Local
  • Notification Mail : SMTP ( is just link and Questionnaire name )
  • Response Pdf : Aspose directly as template is created during Questionnaire creation
  • Concerto Link Out-Of-Scope for MVP ( see rework Concerto )
  • Concerto input and response will be manual for MVP
Picture
Picture
]]><![CDATA[RIZIV / INAMI : Fiche Fiscal - Part of GenPay]]>Thu, 05 Sep 2024 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-fiche-fiscal-part-of-genpay7631275Change upon : ADR-2023-06 & ADR-2024-03

Overview

  • Has been taken over by another team and now is returned to initial team
    • Development : Bram – Yassin
    • Support : Charlotte – Tom
  • Has been released and status has been changed from Project to Product 

Changes in InfraReq

  • Before handover the team made some cleanup’s and last version migrations
    (.Net 8, Code clean-up, …. )
  • A future proof change was to encapsulate the 2 Processing part into the WebService
    ​( before windowsService ) 
Picture
Picture
]]><![CDATA[RIZIV / INAMI : Established Rights]]>Thu, 05 Sep 2024 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-established-rights

Other Names 

  • VastgesteldRecht
  • Droits Constatés

ambiguous language

  • Ordiges ( Finance supplier )
  • Ask&Go : Acceptance application from Ordiges that sends accepted rights / Payments to PIA
  • PIA : Finance application from Ordiges

Overview

API between business applications and Ordiges ( Finance )
  • We deliver the Rights to Ask&Go ( Ordiges – Acceptance Part )
  • We check the status ( ask&Go and PIA )
  • We store the Benificiares in PIA ( FinFiscData will be linked to PIA ) 

InScope

  • API (OutgoingRights / Benifs )
    • Validation
  • Internal bus
    • retries
  • Client Package
    • Use of both API’s
  • External bus
    • API requests
    • API Responses
  • Migration
    • HangFire Jobs handler
  • MyPortal-FrontEnd
    • FinFiscData ( using Benifs-API )
  • FileShare
    • Migration
    • Backup / debugging
  • FrontEnd
    • Dashboard

OutScope

  • API (Incomming right )
    • Validation
Picture
Picture
Picture
]]><![CDATA[RIZIV / INAMI : eMailIn- Part Of IOC]]>Thu, 05 Sep 2024 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-emailin-part-of-ioc

eMailIn is een Client van IOC 

Overview

  • Why Connector email IN
    • Connector email IN is the evolution of an existing functionality implemented through the Kofax scanning software
  • Needs of Connector email IN
    • We need to extend the functionalities compared to the existing
    • Capacity to capture emails in other folders than the inbox
    • Capacity to capture emails without deleting it from the email folder
    • Capacity to interact with the metadata of the email (i.e. the category and creating custom metadata)
    • Capacity to aggregate the emails addresses into one technical mailbox (Kofax doesn’t allow the usage of alias) (Cost reduction of +/- 3.000 € a year)
    • We must stop using this kofax functionality (to be able to outsource the scanning of the letters)
  • Architectural setup of Connector email IN
    • This will be recuring process (Hangfire) that check the emails (through msgraph) and inject it in eDoc Flow.
    • We need to be able to contact the infrastructure of Microsoft 365 to interact with the  mailboxed
  • what is changing
    • The capture of the emails (from the mailbox) was done through the Kofax application
    • This will be done through our own connector ( HangFire Job Service ) 
Important Note :
  • eDocFlow is being renewed -> ARB comming soon
  • Change is needed before Renew Planning
  • Current change is still setup in the old setup but is ready for the new proposal
Picture
]]><![CDATA[RIZIV / INAMI : eDocFlow]]>Thu, 18 Jul 2024 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-edocflow

Replacement of Ioc

Picture

Hands on working on the POC became MVP and Phase2

Picture

MVP Planning : 

  • January First Tests
  • February ARB + InfraReq + TST Deploy 
  • March April 
    • Setup handOver
    • planning IOC Clients Migration towards eDocFlow Clients
    • 1 by 1 switch Client Fluxes from IOC towards eDocFlow
]]><![CDATA[RIZIV / INAMI : eDosServices]]>Wed, 26 Jun 2024 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-edosservices

Reason

  • eDos is a dossier applications for the Medical Control and Study Department inspecting Care Personnel/Institution on (para)-medical prestations. ​
  • eDos is also Accessible  to concerned and also representative (magistrate/lawyers) via eDosServices
  • eDos is a Case 360 Migration project
  • eDos project is seperated in Appian ( eDos ) and .Net (eDosServices)
    • eDosServices
      • As there are multiple issues connecting the FO and BO to Appian the team has created a full .Net Setup connected through the API with Appian.
      • The full .Net structure has been delayed ( See Appian current history) and now the Architecture has to be ARB- Reviewed

Overview

eDosServices is setup as a Default 3 layer application into the eDos landscape
  • 3 layer
    • WebFrontEnd
      • Blazor BackOffice ( BO )
      • Blazor FrontOffice ( FO )
    • BackEnd 
      • API : .Net 8 API as connection with Appian and the own Database ( not shared )
      • ZipService : a separated WebService special for Zipping – Linked With the dossier to allow download of the full content of the dossier documents by external parties​
    • SQL Database

Planning

  • Team is getting ready for TST deployment 
  • Deadline is end of August in PRD 
Picture
Picture
]]><![CDATA[RIZIV / INAMI : DocTracker - Part Of IOC]]>Thu, 13 Jun 2024 22:00:00 GMThttps://poorbeggar.weebly.com/made-by-john-claes/riziv-inami-doctracker-part-of-ioc

A eDocFlow Client for the PrintRoom

Reason

  • DocTracker is a BackOffice Client to make it possible for the scanroom to ensure their printJobs have been accepted by eDocFlow
    • The manual procedure of scanning a document into eDocFlow has a step to ensure/check that the scanned document is accepted by eDocFlow
    • Changes
      • from Business Application to ICT application
      • from VBA access application to .Net 8 - 2 tier – Blazor application.
      • Added into the eDocFlow Landscape as a eDocFlow Client 

Overview

  • Doctracker is setup as a Default 2 layer BackOffice application into the eDocFlow landscape as a Client
    • 2 layer
      • Blazor webfrontend ( BO )
      • SQL Database

Planning

  • Team is using this as the baseline for the other eDocFlow Clients
    • .Net 8 Migrations
    • HandOver and knowledge backup’s
  • Team has successfully performed the initial tests
  • The hand over has been done,
Picture
Picture
]]>