External System Simulator(ESS)

I will elaborate on ESS. However, if you are interested, we can discuss this further in a meeting. Thank you in advance. Deployment View: Based on the requirements, we should be able to deploy ESS either in the same VPN of the Guidewire's Apps or a different VPN. ESS configurations can differ from caller to caller, so again, based on the requirement, we can deploy one or multiple instances of the ESS Apps responding to the caller systems. Especially for performance testing, you might consider having multiple instances to collect performance metrics separately for each caller App. For the development phase, use one instance of ESS shared across all callers. Define the common backend shared across multiple systems once. ESS setup should be at the deployment level. Caller Apps Configuration: To configure the caller Apps (IS) to integrate with ESS, we must replace the service base URLs with the ig app's URL and add the unique TemplateName as the path parameter to the URL. Ex: {ig-base-url}/{original-endpoint}?essTemplateName=addresslookup To call the ig app from Suite Apps, we must create a client using the RES client framework and share a client jar and a sample code. As a side note, I have created a small framework for generically calling the REST APIs, which can be configured to point to ESS for mocking the service. My point here is that we must have a framework to switch the IS Apps to point to ESS instead of the backend systems, and this shouldn't impose any code change on the users. In a nutshell, Suite Apps should be configurable to determine whether to hit ESS or the real backend systems. ESS System Configuration: The ESS configuration is stored in a file named simulator-config.json (or .properties or .xml file). This configuration will create one route dynamically per the backend's endpoint. The following are the key parameters: TemplatesPrefix, prefix name in S3 bucket, which ESS will load the templates from Timeout Generic, timeout value in msec. A timeout exception (with 500 status) will be sent out if the call takes longer than this value. Backends: this is an array element. One element per backend system gets defined. - Name, name of the backend system (like petstore) - Endpoints, an array of endpoints with the following elements per endpoint. Please note that as described before, for each endpoint at start-up, a router class will be instantiated dynamically using the RouterTemplate - ID, route ID for the router created for the endpoint - OperationType, GET, POST,... (like (GET) - Endpoint path that is self-explanatory (like /petstore/pet/findByStatus) - RequestName, if request exists - TemplateName, if the response body is supposed to be generated, the name of the FreeMarker template - Timeout Override, if applicable, and the timeout is different from the default configuration (Timeout Generic) Velocity configuration: The velocity configuration should be stored in a file named velocity-config.json (or .properties or .xml file). The ESS can be used for isolation performance testing, so we must mimic the backend systems' behaviors. We should be able to configure the ESS to have an average delay based on the NFR requirements defined for the backend systems, to accomplish this, we will define the load distribution graph. This configuration defines a table for the response time, The values are percentages. For instance, you can define that 25% of the calls take 250ms, 50% return between 250 and 750 msec, and 25% respond within 750 to 900 msec. Templates: ESS will use the FreeMarker Apache library templates to create dynamic content by combining templates with data models like REST Request body, parameters, and headers (in case of the rest calls) TemplateName is a name provided as a path parameter to the REST calls. If it exists, a response will be generated. Directives can be used to create the response as needed. Uploading the templates to ESS is a prerequisite for the Caller applications to integrate with ESS. ESS is configured to read the templates from the configured prefix from the S3 bucket. Note: Clients (with the vendor's support) are responsible for creating the templates. One or many templates will be stored in ESS to provide various responses to the consumers for each request. In this case, a pool of templates can be stored in the S3 bucket, and the system will randomly pick one for the response generation. To retrieve a specific type of response from the ESS, we need a bit of design, which I will leave for later to elaborate on. Thank you for your time and patience in reading this about ESS! :)

Performance testing is one of the critical cycles of all the Guidewire projects; by having ESS, we can test (or help clients to test) our applications in isolation from the backend systems, focusing on addressing the issues within the application. Clients can benefit from ESS during the development phase by replacing their backend systems, eliminating the development dependencies, and increasing the team velocity. ESS can be used for the sales demo when we need to have a tailored demo for a client based on their critical integrations by mimicking the behavior of the backend systems in a short period. For BAU and training, it is essential to provide data for all the possible responses to review the UI flows and system behaviors. ESS gets a pool of all responses (FreeMarker FTL scripts)