Publish – subscribe

• Source publishes the Event upon the Topic
• Clients subscribe to a topic ( filtered or not ) to retrieve all published messages
• The Messagebus will multiply the message for every subscriber known upon the moment of publish. 

Concerns

• The content will be "public" and open for everyone with rights upon the Topic

Advantage 

• easy setup and little to none security settings needed ( only on topic level) 

Good to know

• Responses are not given in this scenario

Push-Pop

• Source requests Send rights upon the destination Queue
• Destination retrieves all Messages upon 1 Queue
  • Source is needed to be included in the message if responses are given )
• Destination requests Send rights upon the Source Queue for the responses
  • ​Same response Contract is used, but Destination knows on what queue to send

Concerns

• Rights will become a hassle to maintain as Source and Destination will start to have multiple links

Advantages

• Messages are more secure ( Nobody but destination can even accept/filter/read )
• responses don't need filters upon MessageType of Content/Header value

Good to know

• deployable units need send rights 
• this is also named "Command-Response"

Publish - Subscribe 

• messages are "Public" on the Topic -> Data Security
• responses need to be filtered upon MessageType of Content/Header value
  • ​This means changes for every Source that wants to communicate
    • ​Code - Deploy - Test - VAL - PRD -> TTR ( Time to Release )​​

Push-Pop

• Same messages need to be Send multiple times for every Destination 
  • this is in a Loop by settings or even by Change ( TTR enlarges ) 
• Responses are never implemented or popped 
  • Delays and cost of the bus infrastructure 

When Migration from Contact Contexts are being analyzed we get every time the same questions.

• Contact => Legal Context => Atlas
  
• MedCons => MedCons Context => MedCons 

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. 

For a list of Products we need to start a Re-Writing Project or we start a full new project 

• check Business Architecture
  • What
    • ​Here we add a lot of Enterprise and Software knowledge 
    • The Analysts  have here the power as they are the voice for the business 
  • How
    • Business current working  
    • Business current issues and requests
    • Business added Values and Risks of possible options
    • Guide Business in selection of the option 
  • Delivery
    • Business accepted option 
    • Setup Roadmap 

 

• check Enterprise architecture 
  • What
    • Here we check the current option with the colleagues
    • check setup and implementation and guidelines constraint
  • How
    • Business Risks and Added Value 
    • Technical Risks and Added Value 
    • Enterprise Risks and Added Value 
    • Enterprise setup of the decision 
  • Delivery 
    • Schema of implementation of the project in the Enterprise 
    • Schema of communication with projects / businesses and deliveries 
    • Guidelines for the software / project team 

 

• check Software architecture 
  • What
    • listing stakeholders and dependencies
    • System implanting into the enterprise 
  • How 
    • listing Technical and business requirements 
    • listing stakeholders and dependencies 
      • Transversal use of components ( re-use - SOLID ) 
    • Build Roadmap
      • Plans on Platform and Server Level 
      • communication with the other stakeholders/ dependencies 
  • Delivery 
    • Roadmap 
    • Guidelines 
    • Onboarding lists for the dependencies
    • onboarding documentation for the stakeholders

 

• Communication with application Architect 
  • What
    • Tech lead or application Architect of the project team will take over here and will create the InfraReq's, releases and technical decisions within the created Architectures.
  • How
    • collaboration with 2 weekly follow-up moments
  • Why
    • For some projects the analyses are delivered in a Agile way, what means that sometimes analysis sequences question the current architecture 
    • The use of Transversal components have their own Roadmap on changes and implementations so also upon that level we need to have our own Roadmap  

Fiscal Landscape 

• a Generic Payment project
  
• a Fiscal project generating Fiscal documents
  
• a Fiscal project that connects internal and External projects together for payments of Commissions

Transversal Landscape 

• Document Forwarding and management system 
• servicebus use 

Fraud Control 

• follow up of the rewrite of the main Fraud control application 
• follow up of the rewrite of the Fraud control enrichment of the data 

as the UX team is still working with Code-snippits and our TL's are asking for Components we have started in 2023 a small workForce to work together on a small component Library
The work is being done by several teams 

• Maryam : AvanceOA, GMCI
• Naim : eDocCenter, Concerto
• XXX : ( Nick Maertens, Diederik Krols ) 
• Jean-Paul: edocFlow Clients
• Bram : Colindos
• Charlotte : Established Rights 

Proposition is to get this Component Library as Shared Component ( ​ADR202311-007 ) 

We decided that all architects will look at the current setup of the package and we'll see if they contain components we want to use 

With this we'll come back together to decide 

• Do we put it in the Common and let the TL's and Architects work on it ( Pull requests ) 
• Do we decide against the package 

OK if Context and UseCases are OK 

In bijlage de verschillende usecases voor de rich tekst editor van onze applicatie. De belangrijkste usecase is deze rond beslissingen. Dossierbeheerders en collegeleden moeten beslissingen formuleren op de aanvragen. Deze beslissingen worden overgenomen in verschillende officiële documenten van het college (verslagen van de vergadering), en worden ook overgenomen in de brieven die ter beschikking worden gesteld van de aanvragers. Het gaat vaak om complexe materie waar opmaak voor de dossierbeheerders (oplijsting, schuin en vette tekst) belangrijk was om een professionele en begrijpbare tekst te kunnen formuleren.

Actions : 
Nuget : 
"NuGet Gallery | MudExRichTextEditor 1.0.6" latest version is added to the Feed

OK for Colindos 

Short Overview
As we are moving to the cloud Views are not a possibility anymore as DB’s are not set to be on the same server-DB-instance. 
Contact has already made the communication that it will not allow / support views anymore. 
Contact, RefCodes, Fiscal information, etc … are Applications that have their Business Data used by other applications
The use of this “BusinessData used by others” will impact the possibilities to request the data 
Screen / Show on demand / Use on Demand : Api’s 
What with Exports / Queries ( searches ) / Reporting / batch processing 

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 

Small Common library to enable Identification of the Issuer of an OAuth Token and use the correct Tenant Information to work further with the application using the 'Tenant' information 

• An UserToken is always delivered from 1 IDP ( Issuer ) 
• A Tenant has 
  • a dedicated Database Connection 
  • a Tenant Name 
  • a list of trusted IDP's 
• using this mix of information this library helps the developer to retrieve the Tenant information using the Issue of the UserToken and the Tenant information given by accessing the application.
• Authentication and authorization are not the goal of this library 
  
  

we have a lot of Copy-Paste codes for things we all use.
Examples :

• Iban validation
• CBE Validation
• RR Validation

shouldn't they be packages upon Common Level so everyone can use 1 package and know that the code is maintained/up to date ? And if so :

• where do we place the code?
• what name spacing do we use ?
• how do we validate changes ?

code will be places inside the Common Collection Name Space :

• using the standard naming convention

Examples :

• Nihdi.Common.Validators.Iban_Validator
• Nihdi.Common.Validators.CBE_Validator
• Nihdi.Common.Validators.NISS_Validator

Versioning 

• separate projects so separate versions Validation
• TL's will become Common Collection members so they can add Common components
• Pull requests must be approved by multiple Architects
• Approval Guidelines will follow

In software quality assurance, performance testing is in general a testing practice performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage. Performance testing, a subset of performance engineering, is a computer science practice which strives to build performance standards into the implementation, design and architecture of a system.

https://en.wikipedia.org/wiki/Software_performance_testing

For the moment the proposition is:
In Project (guidelines will be added )

• Local Perf testing ( is indication )
• Anonymous-Data ( Project ongoing )

Perf testing in TST/VAL ?

• Testing on servers ( tool ? )
• Local Perf testing ( is indication and can be done against TST)

Reactive : Dynatrace implementation