# arex-replay-schedule **Repository Path**: zohardev/arex-replay-schedule ## Basic Information - **Project Name**: arex-replay-schedule - **Description**: Automates retrieval and sending of recorded data for targeted application testing and verification. - **Primary Language**: Java - **License**: Not specified - **Default Branch**: main - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 1 - **Created**: 2024-06-09 - **Last Updated**: 2024-06-09 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # Arex Icon AREX Schedule Service ## Introduction Once you have successfully installed the **AREX's Agent** and configured it to use the [`Storage Service`](https://github.com/arextest/arex-storage), you can initiate a replay to verify the impact of new version deployments on your target host. This process helps in understanding whether the changes are as expected or not. ## How to Run a Replay The replay process involves the following steps: 1. **Retrieve Records:** Load all records from the `Remote Storage Service` for each API operation, categorizing them by version. 2. **Prepare and Send Requests:** Organize the request messages and dispatch them to the target host. 3. **Collect Responses:** Upon successful request transmission, gather all response results (including entry and dependent services) using `recordId` + `replayId`. 4. **Result Comparison:** Compare these results as per configurations, categorized by `MockCategoryType` (e.g., HTTP servlet, Redis, DB). 5. **Report Generation:** Send the replay comparison results to the [`API Service`](https://github.com/arextest/arex-api) for analysis and summary creation. ## Important Notes - **Host Availability:** Do not create a plan if the target host is unreachable. - **Error Handling:** Interrupt the plan if more than 10% of request sending results in exceptions. ## Getting Started ### 1. Configuring Connection Strings To set up the connection, modify the default `localhost` values in `resources/META-INF/application.properties`. Here's how you can configure for `Redis`, `MySQL`, and dependent `web services`: ```yaml # Web API arex.storage.service.api=http://10.3.2.42:8093/api/storage/replay/query arex.api.service.api=http://10.3.2.42:8090/api/report arex.config.service.api=http://10.3.2.42:8091/api/config # MySQL spring.datasource.url=jdbc:mysql://10.3.2.42:3306/arexdb?useUnicode=true&characterEncoding=UTF-8 spring.datasource.username=arex_admin spring.datasource.password=arex_admin_password # Redis arex.redis.uri=redis://10.3.2.42:6379/ ``` ### 2. Extending the Replay Sender The `DefaultHttpReplaySender` handles HTTP requests (PUT, GET, POST, DELETE, etc.). To implement a custom sender, follow the `ReplaySender` interface pattern: ```java public interface ReplaySender { /** * Indicate the instance should be working for the message content type, * return true should be used,others skipped */ boolean isSupported(int contentType); /** * Try to send the replay case to remote target host */ boolean send(ReplayActionCaseItem caseItem); /** * Try to send the request message to remote target host */ ReplaySendResult send(SenderParameters senderParameters); /** * Try to prepare the replay case remote dependency such as resume config files */ boolean prepareRemoteDependency(ReplayActionCaseItem caseItem); /** * Try to warm up the remote target service before sending */ default boolean activeRemoteService(ReplayActionCaseItem caseItem) { return true; } } ``` ### 3. Extending Deployment Environments To generate comprehensive reports, additional information such as the target image version and source code author is required. Implement the `DeploymentEnvironmentProvider` interface to provide this data: ```java public interface DeploymentEnvironmentProvider { DeploymentVersion getVersion(String appId, String env); List getActiveInstanceList(AppServiceDescriptor serviceDescriptor, String env); } ``` ## License - Code: [Apache-2.0](https://github.com/arextest/arex-agent-java/blob/LICENSE)