Excel Desktop Client EASAP vs. in-browser EASAP

In EASA there are two ways to run an existing Excel spreadsheet as the core functionality behind an enterprise application.

A User may interact with Excel via two very different interfaces:

With an EDC EASAP a User will create, modify, and save case data to a database from within a temporary, local Excel Client instance
With an in-browser EASAP a User will modify EASAP GUI objects that are linked in 'real time' to spreadsheet cells via an Excel Server

To determine which technology to use, an Author should consider:

Below we briefly compare the two technologies in these four domains,

	EDC EASAP	in-browser EASAP
1.	Very little Author effort to deploy a prototype with full Excel functionality and the possibility of immediate release to production	Initially run the Excel Range Wizard then make manual adjustment for GUI objects, output and 'results' documents. Not every Excel feature is supported, see Supported Excel functionality for an in-browser EASAP.
2.	Automatic and audit-able database persistence in the 'cases' table	DATABASE READs and WRITEs require SQL code and testing.
2.		Complete flexibility about how data is stored.
3.	Local Excel Client instance performs at full native speed within a single Excel process.	Multiple Excel processes in an Excel Server may create a resource bottleneck. RAM and CPU requirements add to production costs.
	A supported version of Microsoft Excel must be installed on any potential User's local machine.	A supported version of Microsoft Excel is installed centrally on an Excel Server and shared by many simultaneous User's.
	Excel is not supported for mobile phones.	A mobile phone browser is a valid EASAP interface.
4.	Data is erased upon close, macros and formulae can be hidden with VBA	By default, no spreadsheet intellectual property is exposed.
4.	Security in Excel is limited by the strength of protection that Excel provides.	A remote Excel Server provides no direct User access to a spreadsheet, an Author explicitly specifies every cell to be linked to an EASAP GUI object.

In general, an Author should consider an Excel Client interface for an EASAP that derives functionality from Excel:

Authoring time is minimal
Database persistence is automatic
High performance is obtained even for spreadsheets with heavy computation
No scalability issues with increasing numbers of simultaneous users
VBA code is provided to hide spreadsheet functionality and data is cleared just prior to close

The choice may be simplified further if an Author should optimize one of the three criteria:

Cost - an EDC EASAP minimizes the time-cost of Authoring and financial-cost of an Excel Server.
Security - an in-browser EASAP maximizes the security of a sensitive spreadsheet as intellectual property.
Performance - an EDC EASAP where Excel is installed locally maximizes performance by using a non-shared Excel instance.

Here is a typical Excel-based in-browser EASAP architecture:

A User selects an EASAP on the EASA Server using a browser
A browser-redirect delegates an Excel/EASAP Server for the duration of the session
The User interacts with the EASAP entirely within a browser
- Input cells are modified,
- Output cells and charts are updated,
- Results may be,
  …displayed on the screen
  …written to *.html, *.pdf, *.xls or *.txt files in the Results folder
  …manually written to rows in a database

With an EDC EASAP and the 'cases' table we have a more powerful and complex architecture than above:

A User selects an EDC EASAP on the EASA Server using a browser
A browser-redirect delegates an EASAP Server
A CASE VIEWER GUI object allows selection of a case from the 'cases' table
- a User selects a 'case'
  - a DATABASE TO EXCEL DESKTOP ACTION,
    1. queries the cases table for case data
    2. initializes an Excel Client instance on the User's desktop
a User modifies cells within an Excel spreadsheet
on the EASA Ribbon,
- EASA→Save will update the record in the cases table

The diagram below demonstrates this functionality.

EASA Help Pages