Integration Layer Middleware across modules

The KEBS Integration Architecture is designed to connect KEBS with an external application server. All inbound data passes through a multi-step validation and transformation pipeline before being stored in the KEBS staging layer.

Inbound Payload Validation

Any data sent to KEBS from an external system goes through these initial validation steps:

• 1
  Payload Size Validation — The system checks that the incoming payload does not exceed size limits.
• 2
  Payload Schema Validation — The structure and format of the payload is validated against the expected API schema.

Data Processing Pipeline

Once the payload passes initial validation, the data is processed through five stages:

After processing, the data is stored in the KEBS Staging Layer, which is then consumed by the respective application layer (e.g., Employee Directory). Staging layer data is cleared periodically based on the data lifecycle policy.

All errors encountered during integration are logged in KEBS and an error trace is created. Notifications are automatically sent to both the external support team and the KEBS team.

Error Resolution Flow

• 1
  The system checks if the error is a payload validation error.
• 2
  If it is a payload error, the payload details are added to the error trace and stakeholders are notified.
• 3
  If it is not a payload error, the system searches the Error Repository for the error code.
• 4
  If a match is found, the probable cause and suggestive recovery steps are added to the error trace and stakeholders are notified.
• 5
  If the error is not found in the repository, a new support ticket is created in KEBS automatically.
• 6
  After the error is analyzed and fixed, RCA (Root Cause Analysis) and CAPA (Corrective and Preventive Action) are updated in the Error Repository.
• 7
  Ticket details and error occurrence information are sent to all relevant stakeholders.

For every new employee hire record in the source system, the Employee Hire API is called once to send the data from the source to KEBS.

For every employee update record in the source system, the Employee Update API is called to send the changed data to KEBS. The field schema is the same as the Employee Hire API (with an additional last_working_date field), using the same field names, types, and KEBS mappings.

Mandatory Fields for Employee Update

For every employee exit record in the source system, the Employee Exit API is called to initiate the offboarding process in KEBS.

API Field Reference

Data Flow Rules

• For inbound data to KEBS, only created or changed data should be sent in the API request from the external application server.
• Employee ID and Email are always unique and must be available for every employee.
• Employee data should not be directly altered in KEBS, except for Project Data, Calendar, and Skills.
• All data field mapping for inbound APIs is processed at the external application’s end.
• KEBS does not support parallel API hits for the same employee APIs with different data for the same employee.

Authentication & Protocol

• All data flows use REST APIs with JSON response format.
• Both KEBS and external systems follow OAuth 2.0 authentication protocol.
• All employees use SSO for login in the production environment, with email as the unique identifier.

Master Data & Configuration

• All master data and configuration is maintained in both systems manually.
• Any addition or change to master data or config in the external system must be raised as a support ticket in KEBS — updates will reflect within 48 hours of ticket creation.
• For any addition or change to the API field config on the external system’s end, a support ticket must be created 48 hours prior to the change.
• If any configuration or master data not present in KEBS is sent in the payload, an error response will be returned.

Employee Lifecycle Rules

• For each employee, there is one Hire record, one Exit record, and zero or many Update records.
• Employee Update and Exit APIs will fail if the employee was not first created via the Hire API.
• Future exit scenarios are not supported — only current exits are processed.
• Employee exit request revocation must be handled manually through a support ticket.