Simulating a weather service response

The data can be simulated using one of the following options.

Option 1:

Enable simulate data source option of the data page and create a data transform to simulate the response.

Option 2:

Associate a simulation activity to the rest connector.

Option 3:

Create a REST service and get the forecast results from the service.

In this scenario, we used simulate data source approach as its easily configurable and have multiple source options. The approach might change based on the strategy we use to forecast the weather forecast service results.

To complete the assignment, accomplish the following tasks:

1. Create a new Rest connector by consuming the weather forecast service.
2. Create a new D_FCbyCoords data page.
3. Configure the new D_FCbyCoords data page to use the REST Connector created in step 1.
4. Create a Simulation data transform to replicate the response as the web service is not available.
5. Create different strategies to have the rain forecast of varying probability.
6. Simulate the data source of the data page D_FCbyCoords
7. Capture the location coordinates (latitude/longitude) of the event location and event days (start date and end date) from the Booking case.
8. Modify the Weather case life cycle to conditionally make preparations if the probability of rain captured part of service response exceeds or equal to 40 percent.
9. Verify the work.

Per the requirement, the forecast needs to occur for all the event days and one day before each event day. When a weather case is created, it needs to have the data (event days, event location details) propagated from the Booking case. One day prior to each event day, weather forecast service is invoked with the event days and location coordinates as parameters.

If the forecast service responds that there is a probability of rain for a specific event day, the case needs to be routed to the weather specialized facility coordinator to make arrangements. Once the arrangements are made, the facility coordinator submits the case and waits for the next forecast.

If the forecast service responds that there is no possibility of rain for a specified event day, the case proceeds and waits for the next forecast.

The process repeats for all the event days. After the forecast of the last event day, the case waits for the event closure. When the event ends, the forecast case gets routed to the weather-specialized facility coordinator for the teardown.

In case the forecast responds that there is no probability of rain, but does indeed rain, the facility coordinator must have an option to manually invoke the arrangements while the case waits for the next forecast.

The case is resolved when the facility coordinator completes the teardown.

The solution is implemented in the WForecast and WForecastInt rulesets. The case life cycle and workflow are designed as shown in the following image.

As the service is invoked by using dates and coordinates as parameters, the service is consumed under FCCoord (forecast by coordinates) class under application-specific Int- layer. There is a possibility that the forecast service can provide services based on the event ZIP code. The FCZip class is created for the ZIP code.

It is assumed that the application-specific constants (Rain Probability and Weather Preparation SLA) can be changed at any point by the business and it needs to be easily configurable.