# How to Choose Your Business Reporting Solution When using our InsureMO platform, one common question that arises is how to obtain a business data report. This article provides several options that you can choose from at your convenience. ## DataMO First and foremost, InsureMO platform offers an out-of-the-box reporting solution called DataMO. We highly recommend adopting DataMO for all projects, as it provides the best solution for report extraction in both development convenience and performance. DataMO includes a separate Relational Database Service (RDS), ensuring that normal transactions are not affected. It also provides a configuration studio for data conversion. If you have multiple transaction tables, you can easily merge the data into a single, large table once the transaction database is synchronized with the DataMO database, greatly simplifying data extraction. The downside of DataMO is that it incurs a separate subscription fee. For more details on pricing, please contact the InsureMO support team. ## Replica Database (Replica DB) If you find the DataMO subscription too costly or if you prefer a simpler approach, the second option is to use a Replica DB. With a Replica DB, you can utilize your own SQL scripts for data extraction, making the process straightforward. A Replica DB operates as a separate entity, ensuring that your transactions are unaffected even during extensive data extraction. One limitation of using a Replica DB is that you may need to add additional database indexes to certain tables to maintain extraction performance. This requires approval from the platform team. Additionally, a Replica DB incurs a separate infrastructure cost, which is considerably lower than DataMO. ## API-Based Approach (ES Search Only) By default, the majority of our transactions are supported by an API related to Elasticsearch (ES). This API not only facilitates searching but also allows for data downloading. Our platform provides an out-of-the-box query user interface that supports download APIs. The API-based approach offers excellent performance and ease of invocation. However, this method has a potential drawback: it may not be capable of extracting all the data that a user might require. In cases where the data structure is straightforward, users can extend the ES index fields to include additional parameters. It is important to note that we do not recommend adding an excessive number of fields to the ES index, as this could negatively impact performance. For scenarios involving more complex data structures, users may need to explore alternative solutions. ## API-Based Approach (ES Search + DB Load) If you do not wish to use DataMO or a Replica DB, an API-based approach can be considered as a last resort. In this approach, you would typically start with a search API and then supplement the data with a load API. Take BCP for instance, if you want to search within ARAP, you would first invoke the ARAP search API. Then, if a user wants to view collection data concurrently, you can call the load collection API, providing the ARAP ID. When using APIs, there are several considerations to keep in mind: * Asynchronous Method: Ensure that report extraction is done asynchronously. This requires a batch process for extraction, S3 storage for archiving reports, and a notification mechanism (such as UI alerts, email, or a message center) to inform users and facilitate report retrieval. * ES API Limitations: The ES API can only support a maximum of 1,000 records per call. You will need to sort by ID and make repeated calls to retrieve all ES data. * Load API Execution: The Load API should be executed in batches of 1,000 records at a time, rather than one record at a time. You will need to identify all the required load APIs, and the platform team can assess whether to provide you with a new batch load API that accepts multiple IDs as input. * Excel Data Entry: Write data into Excel in batches, incrementally, rather than all at once. This approach prevents memory exhaustion when dealing with large datasets. * Reporting Format: Ensure that all reports are presented as lists of records, rather than statistical summaries. The latter would consume a significant amount of resources and may only be feasible with options 1 or 2. ## General Considerations for All Methods Regardless of the chosen method, it is always advisable to impose constraints on search criteria, particularly by limiting the maximum date range that users are permitted to search. ## Comparison Between Different Options | DataMO | API-Based Approach (ES Search Only) | Replica Database (Replica DB) | API-Based Approach (ES Search + DB Load) | | |--------------------------------------|-------------------------------------------------------------|-------------------------------------------|------------------------------------------|--------------------------------| | Whether Support All Report Type | Statistics + Listing. | Listing Only. | Listing Only. | Listing Only. | | Whether Support All Field | Yes. | No. | Yes. | Yes. | | Whether Separate From Transaction DB | Yes. | Yes. | Yes. | No. | | Performance | Excellent. | Excellent. | Good. | Medium. | | Development Convenience | Medium At beginning, then Easy Gradually - Visualized Studio. | Super Easy - ES Index Field Configuration. | Medium - SQL Script. | Low. | | Subscription Cost | New Subscription. | Included in Basic Subscription. | Slight Infra Cost Addition. | Included in Basic Subscription. | | DEV Cost | Low DEV Efforts. | Slight Configuration Efforts. | Medium DEV Efforts. | High DEV Efforts. | | Direct Readiness | Need Notify InsureMO Team to Setup. | Ready-to-use. | Need Notify InsureMO Team to Setup. | Ready-to-use. |