Configuration Guide
This section details the various configuration options available for the Claim Processing System. These settings control database connections, message queue interactions, email services, security policies, and scheduled tasks. Most configurations are managed through Spring Boot's application.properties (or application.yml) file.
General Application Properties
The Claim Processing System leverages Spring Boot's externalized configuration, primarily using application.properties or application.yml. This allows you to manage environment-specific settings outside the application code.
A basic application.properties might look like this:
# Server Port
server.port=8080
# Database Configuration (Example for H2, adjust for others like PostgreSQL, MySQL)
spring.datasource.url=jdbc:h2:mem:claimdb
spring.datasource.driverClassName=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=password
spring.jpa.database-platform=org.hibernate.dialect.H2Dialect
spring.h2.console.enabled=true
spring.jpa.hibernate.ddl-auto=update # Use 'none' or 'validate' for production
# Logging Configuration (Refer to Log4j2 for detailed setup)
logging.level.com.claim.demo=DEBUG
logging.level.org.springframework=INFO
Redis Configuration
The system uses Redis for caching claim statuses and potentially other temporary data. You can configure the Redis connection details using the standard Spring Data Redis properties.
# Redis Connection Settings
spring.redis.host=localhost
spring.redis.port=6379
spring.redis.password= # Optional: if your Redis instance requires a password
spring.redis.timeout=5000ms
The application uses StringRedisSerializer for keys and GenericJackson2JsonRedisSerializer for values in RedisTemplate, which means your keys will be plain strings and values will be serialized to JSON.
Kafka Configuration
The Claim Processing System uses Apache Kafka for asynchronous notifications, including claim status updates and user notifications.
Kafka Broker Connection
Configure the Kafka bootstrap servers for both producers and consumers:
# Kafka Bootstrap Servers
spring.kafka.bootstrap-servers=localhost:9092
Kafka Producer Configuration
Producers send messages to Kafka topics. The KafkaProducerConfig class sets up producers for NotificationDTO objects.
# Default Producer settings (usually inherited from spring.kafka.bootstrap-servers)
# spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer
# spring.kafka.producer.value-serializer=org.springframework.kafka.support.serializer.JsonSerializer
Kafka Consumer Configuration
Consumers listen to Kafka topics for specific events. The KafkaConsumerConfig class defines a listener for claim status updates and handles email notifications.
# Kafka Consumer Group ID
# This group ID is used by consumers to ensure messages are processed by only one consumer within the group.
spring.kafka.consumer.group-id=group_id
# spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringDeserializer
# spring.kafka.consumer.value-deserializer=org.springframework.kafka.support.serializer.JsonDeserializer
Important Note on Topics: The application uses several Kafka topics:
claim-status-updates: Used byClaimServiceto publish status changes.claim-updates: Monitored byKafkaConsumerConfigto trigger email notifications based on claim status updates. Ensure consistency: TheClaimServicepublishes toclaim-status-updates, but theKafkaConsumerConfiglistens toclaim-updates. You might need to adjust one of these for proper end-to-end flow.user-notifications: Used byNotificationServicefor general user subscriptions.unsubscribe-notifications: Used byNotificationServicefor unsubscribe events.
Ensure your Kafka environment has these topics created and accessible.
Email Configuration
The system can send email notifications, particularly for claim status updates. Configure your SMTP server details for JavaMailSender through Spring Boot's mail properties.
# Email Service Configuration (SMTP)
spring.mail.host=smtp.example.com
spring.mail.port=587 # or 465 for SSL
spring.mail.username=your_email@example.com
spring.mail.password=your_email_password
spring.mail.properties.mail.smtp.auth=true
spring.mail.properties.mail.smtp.starttls.enable=true
spring.mail.properties.mail.smtp.starttls.required=true
The default sender address is no-reply@example.com, as defined in EmailService.java. This can be overridden programmatically or potentially through a property if EmailService were refactored to use a configurable from address.
Security Configuration
The Claim Processing System employs Spring Security with OAuth2 for authentication and authorization, utilizing JWTs (JSON Web Tokens).
JWT Signing Key
A critical security configuration is the JWT signing key defined in AuthServerConfig.java. For production environments, this must be a strong, secret key that is not easily guessable and should be securely managed (e.g., via environment variables or a secret management service).
// AuthServerConfig.java
converter.setSigningKey("signing-key"); // DO NOT use "signing-key" in production!
Recommendation: Externalize this key by retrieving it from an environment variable or a secure configuration vault. For example:
// AuthServerConfig.java (Example for externalizing)
@Value("${security.jwt.signing-key}")
private String signingKey;
@Bean
public JwtAccessTokenConverter accessTokenConverter() {
JwtAccessTokenConverter converter = new JwtAccessTokenConverter();
converter.setSigningKey(signingKey);
return converter;
}
Then, define security.jwt.signing-key in your application.properties or environment variables.
Endpoint Access Control
The SecurityConfig class defines the access rules for HTTP endpoints:
-
Public Endpoints:
/login/registerThese endpoints are accessible to unauthenticated users.
-
Authenticated Endpoints:
- All other endpoints require authentication. Users must provide a valid JWT to access them.
The system is configured to be stateless (no HTTP session is created or used) and CSRF protection is disabled, as JWTs are immune to CSRF attacks.
Scheduled Tasks Configuration
The ClaimBatchService includes a scheduled task for processing pending claims.
Cron Expression
The processPendingClaims method is configured to run hourly using a cron expression:
// ClaimBatchService.java
@Scheduled(cron = "0 0 * * * *") // Runs every hour at the start of the hour (e.g., 01:00:00, 02:00:00)
public void processPendingClaims() { /* ... */ }
You can customize this cron expression to change the scheduling frequency. Standard cron expression format: second minute hour day-of-month month day-of-week.
For more complex scheduling needs or to manage scheduled tasks, refer to Spring's @EnableScheduling and @Scheduled documentation.
Logging Configuration
The Claim Processing System uses Log4j2 for logging. While basic logging levels can be set in application.properties (as shown in the General Application Properties section), detailed Log4j2 configuration is typically managed through an external log4j2.xml or log4j2.properties file placed in the src/main/resources directory.
Example log4j2.xml for detailed logging:
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
<Appenders>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
</Console>
<File name="File" fileName="logs/claim-processing.log">
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
</File>
</Appenders>
<Loggers>
<Logger name="com.claim.demo" level="debug" additivity="false">
<AppenderRef ref="Console"/>
<AppenderRef ref="File"/>
</Logger>
<Root level="info">
<AppenderRef ref="Console"/>
</Root>
</Loggers>
</Configuration>
This example configures console and file logging with different patterns and sets the com.claim.demo package to DEBUG level.