Onboarding steps to Access SMDS API/EMP/Database

• Events (RETINA)
• API
• Database - Read Replica
• Point of Contact

Before granting access to any data consumption pathways, it is essential to address and document the following questions in Confluence:

Events (RETINA)

---

• RETINA Topics and Consumption Strategy:
  • Our EMP topics are log-compacted, ensuring that all records are retained indefinitely. To avoid unnecessary overhead, it is recommended to begin consuming from the latest offset. Starting from offset=0 will load all historical FMD records from the respective topic into your database. This behavior can be leveraged in lower environments for performance testing to validate seamless consumption under high outbound load scenarios.
• GDPR Compliance for SMDS Master Data:
  • In accordance with GDPR regulations, all SMDS Master data must be stored exclusively within the European region. Please ensure that your system design and architecture fully comply with this requirement.

The following details must be documented here: Integration Landscape before granting access:

1. Application Name(s)
2. Required Topics (e.g., Vessel)
3. Primary and Secondary Points of Contact
4. Team Email List (Distribution List)
5. Detailed Business/Benefit Case and utilisation plan
6. Application ID(s) to be added to the consumer list
7. Tentative Dates for SIT, PP, and Production consumption (please send email confirmation of successful consumption testing in each environment)
8. Tentative Date for Bulk Testing in either SIT or PP (to avoid surprises in production during high outbound loads)
9. Confirmation of Successful Testing (Commit to sending email confirmations after successful consumption testing in each environment.)
10. Data Retention Requirements
11. Error Handling and Retry Strategy
12. Primary Fields the Application Will Consume**:**

• Specify the key fields or data elements the application intends to consume from the Kafka topic(s).

13. Application's Role in Modifying Master Data:

• Will the application modify the master data and forward the updated data to downstream systems? If yes, provide details.

14. Design document

API

---

If APIs are to be exposed, the following details must be captured and documented here: Integration Landscape

API Integration and Usage Requirements Checklist

1. Requested Proxies :
2. Application Name(s):
3. Primary / Secondary Point of Contact:
4. Team Email List:
5. Benefit Case & Planned Data Usage:
6. Tentative Dates for SIT, PP, and Production Consumption (Please confirm successful consumption testing via email in each environment):
7. Peak Hour Load:
8. Average Daily Load:
9. Business Impact in the Event of API Downtime:
10. Duration for Which API Access is Required:
11. API Availability Requirements (Uptime and Availability SLAs):
12. Security Requirements (Compliance Standards):
13. Data Sensitivity (Privacy Regulations):
14. Error Handling (User Communication Protocol):
15. Performance Metrics (Expected Response Times During Peak Load):
16. Scalability Requirements (Projected Future Load Increases):
17. Integration Points (Other Systems or Applications for Integration):
18. Testing Requirements (Specific Tools or Processes):
19. Documentation (Required Level for API Usage):
20. Support and Maintenance (Designated Responsible Parties):

Database - Read Replica

1. Reason for Database Usage Instead of EMP Consumption:
   1. Provide a detailed explanation of why consuming directly from EMP topics is not feasible for your application.
2. Application Name(s):
   1. List all applications that will access the database.
3. Primary and Secondary Points of Contact:
   1. Specify the names, email addresses, and phone numbers of primary and backup contacts for communication.
4. Team Email Distribution List:
   1. Provide the team’s distribution list for updates and notifications.
5. Business Benefit Case:
   1. Explain the business need and intended use of the data. Clearly outline how this will benefit your application and its stakeholders.
6. Impact Confirmation:
   1. Confirm that experienced data experts will handle this connection, as improper usage or high query loads could negatively impact other production systems.
7. Planned Start Date of Usage:
   1. Specify the date when the application will begin accessing the database.
8. Planned End Date of Usage:
   1. Indicate the expected end date for database access, ensuring this remains a temporary solution where feasible.
9. Data Access Scope and Frequency:
   • Define the specific data tables, fields, and access frequency (e.g., daily, hourly, or ad-hoc queries) to avoid unnecessary load on the database.
10. Expected Query Volume and Performance Impact Assessment:

• Provide an estimate of query volume and confirm if performance impact analysis has been conducted to ensure minimal disruption to other systems.

11. Security and Compliance:

• Confirm that appropriate security measures, such as encryption and role-based access, are in place to protect sensitive data.
• Validate compliance with data regulations (e.g., GDPR, local policies) based on the region of usage.

12. Fallback and Migration Strategy:

• Provide a strategy to migrate from database usage to direct EMP topic consumption when feasible.

Point of Contact

Approver Name	Role	Integration
Rahul Singh	Senior Platform Architect	API, EMP, DB (SMDS-CMD/OPS)
Ramesh Varma Kutcherlapati	Senior Solution Architect	API, EMP, DB (SMDS-OPS)
User f2cfd	Senior Data Engineer	API, EMP, DB (SMDS-OPS)
Gopala Krishnan Rajendran	Senior Data Architect	API, EMP, DB (SMDS-CMD)
User e8ff2	Data Product Delivery Lead	API, EMP, DB (SMDS-OPS)
Ajit Vijay Daware	Senior Engineering Manager	API, EMP, DB (SMDS-CMD)