Delivery Process

Step 1: Profile Event Processes
For the event processes in the _apps folder, a replace Environment task is run which looks for the profile enable property place holder and replaces them with the environment specific value as looked up by the {ENVIRONMENT}.properties file.

The modified applications are placed in the apps directory which will be input for the rest of the process.

Step 2: Connect to the configured Enterprise Server
The utility will then attempt to connect to the configured Enterprise Server and try to perform a login with the user and credentials configured in build.properties. The user provided should have the permissions to read/delete/create applications and services in the Fiorano environment.

Step 3: Import Applications

1. If there are no applications to be deployed, this task will not be invoked.
2. For every event process in the apps folder, it is first checked if the process if currently running.
3. If not the event process is imported and continued to the next event process in list.
4. If it's running, then the event process is stopped safely and then the event process is imported and the event process is marked to be launched at the last step of this task.

Stopping Applications Safely

This means that the application is stopped without any message loss. Normally when an event process is stopped, the destinations which were auto created for the components in the event processes are removed and so are the pending messages on those destinations. If the message loss is not acceptable, then the inbound components (components which pump in messages or the entry point of the event process) are stopped first and after a sufficient amount of time for the messages which are already in progress are completed, the event process can be stopped safely.

The task of stopping an application safely is carried out as

1. The logic determines the components as inbound component if it satisfies one of the following conditions
   1. No input port
   2. No incoming Route on any of the input port.
2. Such components are automatically calculated for the application and if no such component exists then a message displays asking the user to manually stop the 'logical' starting point, make sure all pending messages are processed or saved for later execution by browsing at the destination level and getting the pending messages on the destination and after he does that press enter.
3. The list of inbound components is stopped sequentially in random order.
4. Then the utility waits for the specified APPLICATION_STOP_WAITING_TIME, and then the application is stopped.

For cyclic event processes (request-response or synchronous) stopping the in-bound components will not process the messages on the queue and hence the message loss in this scenario is un-avoidable.

Step 4: ImportComponents

1. If there are no components to be imported, then this task will not be invoked.
2. For each component zip extract in the components folder the following tasks are performed.
3. The list of components and libraries which are dependent on (or referring to) this component are calculated.
4. All the running event processes are examined if any of its service components belong to the list calculated in step 3 or is itself the component to be imported.
5. For all such running event processes, a safe stop is issued to the event processes and marked to be launched later. (refer the previous section on the details of the safe stop)
6. The component or the library is then imported. 

Step 5: Launchallstoppedeventprocesses
All the event processes which are marked to be launched are launched after performing a connectivity and resource check. These event processes should have cache set to no for the imported components to be reflected in the peer server during the connectivity and resource check.