Around June 2004, Microsoft released Smart Client Architecture and Design Guide, in the article, Microsoft listed 3 important characterizes of Smart client application:
- It offers rich user experience like normal window application, unlike normal web application
- It works in disconnected mode. ( MS call it Occasionally Connected)
- It can be deployed by “no-touch deployment” technology and capable of self-update
An example would be like a salesman carries his laptop walking into his customer office, he should be able to show the product catalog, take orders when talking to his customer when the laptop is disconnected. However the orders will be uploaded to the ERP or MRP system, and you should be able to synchronize the product catalog when he get back to his office and connect the laptop to the company network.
To make it possible for the application to function in disconnect mode, the application needs to stored it transactional data and reference data… To facilitate this kind of functionality, Microsoft introduced concept of Compact DB and database synchronization framework.
On the other end, around April 2003, Microsoft release Caching Application Block as a member of Enterprise Library ( in fact, Avanade is the company behind all enterprise Library development, and I happen worked for Avanade for 3 years from 2004 to 2007). http://msdn.microsoft.com/en-us/library/ee957904.aspx
This is what it says about caching, “Caching techniques are commonly used to improve application performance by storing relevant data as close as possible to the data consumer, thus avoiding repetitive data creation, processing, and transportation.”
Okay, enough stuff about Microsoft technologies. Let’s move on to our life, BAM. First of all, I have reviewed all non-functional requirements of MI VBAM, it was not our goal to design and develop a smart client. It was not our goal to make it still functional in disconnected mode. But we are using Compact DB and database synchronization framework.
If you look at the data that is been synchronized, you will find more than 70% of data is not supposed to be changed, the other 30% is just some reference data, there is no 2 way synchronization needed. no transactional data is involved in the synchronization process. Basically, we use it as caching solution.
To give you some feel about what kind of data we are loading to the compact DB and involved in the synchronization process, I list some tables ( not complete list, in total there 333 tables ) as following:
- REF_CUSTOMER_TYPE
- REF_ID_TYPE
- REF_CONTACTS
- REF_ADDRESS_TYPE
- REF_STATE
- REF_CITY
- REF_SUFFIX_CODES
- REF_COUNTRY_CODE
- REF_INTL_MILATARY_STATE
- REF_INTL_MILITARY_CITY
- REF_CONTACT_TYPE
- REF_MODE_TYPE
- REF_INDIVIDUAL_CHARACTERISTICS
- REF_BUSINESS_ROLES
- REF_CITY_ZIPS
- REF_COST_EXEMPT
- REF_DAMAGE_REASON_CODES
- REF_FUEL_TYPE
- REF_GROUP_TYPE
- REF_IMAGE_TYPE
- REF_NAME_TYPE
- REF_PREFIX_CODE
- REF_SALE_TAX_OUT_OF_STATE
- REF_SALE_TYPE_CODE
- REF_STOP_ACTION
- REF_TAX_EXEMPT
- REF_VEHICLE_BODY
With that, I am propose the following suggestions
- Review this 333 table to remove these tables that data is not manageable by user. A clear cut would be if we defined a enum in our code, for the same data, we do not even need the data in the server database… please refer to the link https://external1.collaboration.hp.com/external/MIBAM-R1/MI%20BAM%20Cookbook/Enum%20types%20and%20Ref%20tables.aspx for some detail.
- do away with Compact DB and synchronization framework.
- Employ Caching Application Block to cache the data need to be cached in both Client (Process Controller) and server side (BO layer)
Just so you know, Caching Application Block is the application block that is most easy to be employed… 10 minutes would be enough for you to know how to use it… by doing this, the problem we are facing in Compact DB and database synchronization framework will no longer exist…
No comments:
Post a Comment