eScript–Nested ‘with’ has problems in 8.1.1.5

Recently we had the friendly guys from Oracle come over and review our current project. Over the years, we have had review comments coming from such reviews and now know what to expect. But this time, there was a new entry in the document.

Siebel eScript developers and basically anyone who has worked on ECMA style languages must have used the ‘with’ statement. The with statement assigns a default object to a statement block, so you need to use the object name with its properties and methods. Its makes coding easier when you need to do multiple actions on the same object. But nesting with statements , it seems, is not a good idea if you are planning to upgrade to version 8.1.1.5 which came out last year.

The With statement structure indicates that all methods within its block will be based primarily on the indicated object. When With blocks are nested, it is not immediately obvious which object’s method will be invoked. The code execution may not do what the developer intended.

with(firstbc)

{

ClearToQuery()

ExecuteQuery();

with(secondbc)

{

ClearToQuery()

ExecuteQuery();

}

}

If the script remains unchanged prior to upgrading to 8.1.1.5, there is a known defect where runtime errors will occur. Although this is currently considered a defect and intended to be corrected, nested With blocks are not a recommended scripting practice. All of the methods invoked in the second With block would also work on the object in the first With block. In this script, the developer was actually done using the firstbc object prior to starting the nested With, but simply chose not to close the block.
Now oracle says that :It is not recommended to nest With blocks. The first With block should be close prior to initiating a new With block or the object variables should always be used.
Now we have used countless nested with statements it handle complex business logic, and have never faced an issue. But we are now rewriting the code eliminating nested withs and using the complete object names. This is because we do have plans to upgrade some time in future, and its best to steer clear of rework then.

with(firstbc)

{

ClearToQuery()

ExecuteQuery();

secondbc.ClearToQuery()

secondbc.ExecuteQuery();

}

Update: Oracle SRs are here and here

New Year, first post.

 

Happy New year ,everyone. Yeah, I know, this post is long overdue.  I changed jobs some time last year, and the work at the new place is not exactly what I expected.  Crazy deadlines, unrealistic requirements, last minute changes…the works.

But I did get to learn more about this whole CRM world.. And here’s hoping I find more time to share more of what I learn.

I began my career on Siebel 5 years ago, and it has been my bread and butter. The tried and tested On-Premise mode of CRM installation has always been popular with the blue chip and Fortune 500 clients I had the opportunity to work for.  Although cloud based applications are gaining foothold, most of my employer’s clients steered away from sharing mission critical data on the web. They seem to feel more comfortable maintaining and storing their customers data in company’s storage rooms. A lot of them have have simply said no to SalesForce CRM because they don”t get to secure their customer’s data. But all that is changing.

SalesForce.com has understood this customer concern, and the have decided to do something about it. This year, they will introduce a new feature called Data Residency Option or DRO. Simply put, DRO will enable On Premise storage of mission critical data on Cloud.com servers, which can be setup inside client office locations.

DRO will be a part of database.com - a cloud database Salesforce made generally available. It gives an option to the customers of Salesforce to store their mission critical data at their own location and hence keeping complete control of the inward and outward flow of the data across the customer firewall.

The technique developed by Navajo, also called Virtual Private Saas, provides the cloud vendor, Salesforce.com in this case, a key that enables it to translate the encrypted data as it passes through its cloud application. The data is then re-encrypted as it leaves the cloud vendor's solution and returns to the customer's data source. The corporate data is unreadable on cloud provider's servers during this entire operation. VPS is available both as a cloud service, as well as an appliance sitting on the customer's local or Wide area network. With VPS, the customer is solely responsible for its data security as it will hold all the encryption keys.

The flip side to using such a technique would be the security of the encryption and decryption keys used for the process. It is highly critical to properly manage the keys as once the key is lost, the encrypted data can no longer be accessed. Hence, this calls for robust key management to avoid any such eventuality.

But, barring the above, In my view, this technique will overcome the most important impediment to cloud adoption and will be a foundation of technological acceptance as it addresses the key customer fear i.e. about potential data threats in the cloud.

Coming to the acquisition, Navajo systems, founded in 2009 was one of the existing encryption service providers for Salesforce. Salesforce decision to acquire Navajo hence made a lot of sense when other cloud based CRM tools such as Sugar CRM already has possible options for deployment on public clouds (Amazon EC2, Rackspace etc.), private clouds such as VMWare and also on-site behind customer firewalls.

According to a recent report from IBIS World, one of the world's largest independent publishers of U.S. industry research, CRM industry today stands at 60% on-premise deployments and 40% cloud based solutions (1). For customers who are looking for new purchases or upgrade of their legacy applications, DRO might just be the key decision influencer. Let's wait and watch!!

References:

(1) http://www.destinationcrm.com/Articles/Columns-Departments/Insight/Are-CRMs-Worst-Years-Behind-It-79254.aspx