White Paper. The Power of Siebel escripting at Runtime. Bringing Siebel Developer Closer to Rapid Application Development

Transcription

1 White Paper The Power of Siebel escripting at Runtime Bringing Siebel Developer Closer to Rapid Application Development A Simple Technique to Boost Productivity and Improve the Quality of Scripting in Siebel Introduction Siebel CRM is clearly the market leader in CRM. Siebel Systems helped define the term CRM and sell the idea to businesses large and small. While the product is great, customization through scripting has generally been an area where Siebel was never strong, always lagging compared to traditional development environments. This was due to the fact that Siebel Systems had no interest in developers writing code, as that would get in the way of upgrades. While scripting is generally a last resort, it seems to happen a lot in projects. And when it does, the result is rarely as robust as end users would like. Siebel has made many changes to their Tools environment over the years, to help bring it to modern-day development standards. And yet, coding remains tough, debugging is clumsy and it is difficult to isolate pieces of the application and test them independently. The resulting code is brittle, often lacking modularity, with poor error handling. In this paper we set out to identify what we think are the chief reasons for poor scripting. We then propose a new technique and a simple, yet powerful tool to address the underlying problems. Building Quality through Iterations Most experienced developers who write code will tell you that unless you are writing something trivial, it will not work the first time you write it. There are many reasons for this, but mostly it s because writing a new piece of code is partly done through discovering what does and does not work. Therefore, the key skill in development is not so much knowing syntax or having perfect logic, but knowing how to debug your code and improve it incrementally. Typically, developers go through several iterations of code-compile-test before they reach a solution that works in all situations. So, we have determined, over the years, that in Siebel, just like any other development environment, what matters is how quickly a developer can go through the code-compile-test cycle and learn what works.

2 The Challenge with Tools Siebel Tools has traditionally been a fairly clumsy place to write code. In recent versions, it is getting better, providing features like IntelliSense and syntaxhighlighting, and more recently the fix-and-go feature in Siebel 8.0. Nice as these features are, they don t make it any easier to answer questions, such as: 1. You can t not easily extract a piece of code like a simple function and test it independently to see what it would return with different input parameters. 2. You still have to compile your code initially, before you can use advanced features like Fix-and-Go. 3. You can t play with Browser scripts just Server script. Ok, this one is not the end of the world, but nice to have. 4. You can t quickly and easily try out things on your server like writing script and running it directly on your server without even having to deploy an SRF. 5. You can t experiment with server-side components, such as MQ, integration or anything else that does not run well in the Mobile Web Client. 6. If you need an instant answer to a question such as how does the indexof() method work on strings is it 0-based or 1-based? You are itching to code it somewhere e.g. SomeString.indexOf( Some ) and run it. If you did, you would instantly know from the value of the expression, that it is 0-based. 7. If you are wondering what SQL the EAI Siebel Adapter generates when you do a Synchronize vs. an Upsert, how can you quickly test it? 8. Say your tester found a situation where your script is not working. It would be nice to be able to jump right on their Thin Client (possibly using remote desktop) and right on the failing screen, check out what fields are active, what profile attributes were set. The list goes on and on. The basic challenge with Tools is that it is not geared towards allowing you to quickly learn from mistakes. Instead, it is simply a vehicle to get your script into the SRF. What you need is a runtime experimentation lab that would allow you to try out scripts and built-in components in many different ways and learn how they work as you craft your script.

3 What about Documentation? Surely you can read it to learn, instead of doing trial and error learning. While useful, documentation for any product and Siebel in particular, has several issues: 1. Developers are notorious for not reading documentation. They would much rather: a. Copy someone else s code that looks like it may work; b. Write their best guess in code and then run the code-compile-test cycle to learn why and when it doesn t work; c. Ok, sometimes, in frustration, they will look at the docs, but 2. The Siebel documentation is notorious for not providing meaningful examples, if any. This, of course, is part of the discourage scripting strategy, which we can t blame them for, as they are a vendor and it s in their best interest. 3. It is impossible to cover every coding possibility in documentation. You need to try it out. And quickly.

4 An Interactive Siebel escript Execution Console The codeferret In our tireless multi-year efforts to demystify and simplify Siebel scripting, we have come up with a new tool the codeferret, which allows developers to take a different approach to scripting altogether. What is the codeferret? It s an elegant Siebel escripting console window that can be opened with a single key-stroke on both the Web Client and Thin Client, it runs alongside the Siebel application inside your session, and allows you to execute arbitrary code inside your Siebel session. Here is a screenshot: As simple as it sounds, the codeferret comes in very handy and solves a lot of the challenges outlined in the sections above. All you have to do is write the code in the upper (Input) pane. You then press the Server or Browser button to execute your script against the OM or the Browser, depending on what you are testing. The results instantly show up in the lower (Result) pane.

5 In the section below we ll go over a simple example which illustrates the power of using this technique. Suppose You re Wondering how Some Function or Component Works Let s say you are writing a piece of code which would calculate how many days there are between two dates. Let s go through a typical thought process, assuming we are completely new to this problem. You know there is a Date() object, but you don t see any methods to add and subtract dates. So, you look at the other methods available most of them get and set different components of the date, but none of them does arithmetic. You wonder: What if I create two date objects and try to subtract them would that work? So you type into the input pane of the codeferret: var d1 = new Date( 6/5/2007 ); var d2 = new Date( 6/4/2007 ); // some date // previous date return d1-d2; // difference between the two Oddly enough, you get this in the result pane: Now, you wonder, what the heck does this number mean? So you change the dates to see if the number changes: var d1 = new Date( 6/5/2007 ); var d2 = new Date( 6/3/2007 ); // some date // two-days ago return d2-d1; // difference between the two The new result is double the initial number (you can divide them in the codeferret): Clearly, this number somehow represents the difference, so you wonder if it is in seconds. To calculate the days in seconds, you type the following into the codeferret: 24*60*60 // twenty four hours x 60 minutes x 60 seconds And you get the answer in the result pane: Ok, so there are 3 more 000 s in our d1-d2 example, so then you conclude it must be in milliseconds.

6 At this point we have discovered that this works, and that all we need to do to write our function is create two date objects, subtract them and divide the difference by Problem solved! Now, you can test out a function in the codeferret before you plug it into Tools. You type it out in the Input Pane: function DateDiff( d1, d2) { return (new Date(d1)-new Date(d2))/ ; } return DateDiff( 6/3/2007, 6/1/2007 ); Notice how we defined the function, then we immediately unit-tested it below by calling it with some test values and returning the result to the Result pane of the codeferret, which, as expected, shows: 2 That s it. All you do now is copy and paste your function in Tools, knowing with absolute confidence that it would work before you have ever compiled it into the SRF. This is just a very simple example, but it shows you the power of being able to instantly know if something will work or not you just try it and know right away. No need to compile, fix-and-go, or anything in fact no need to fire up Tools at all until you are ready to enter your code. In fact, there is even no need to fire up a Web Client you can just point your browser to the Thin Client and know instantly from anywhere you have access. Conclusion We have seen this concept in use on a project which is worth around $35M, involves 4000 users and is heavily integrated with a large proportion of scripting and heavy use of EAI. On average, once developers make a shift in perspective and freely use it, the codeferret will save you 30% or more in development time alone. On a $35M project, of which $3-5M is spent on development, and with scripting comprising 30% of the total development, we are talking a savings of around $270,000 to $450,000. Even if scripting was only 10% of the project work involved, you are still talking $90,000 to $150,000 savings. In addition, the speeding up of the code-compile-test cycle leads to much better script quality, as developers can experiment and unit-test with flexibility and ease. Finally, this tool is not limited to just writing code prototypes. It can be successfully used to import/export data from Siebel IOs, get/set profile attributes, and automate unit tests for Business Services.

7 New applications of this elegant and helpful tool are yet to be discovered. So, we encourage you to give this technique and tool a try, we believe you will see the benefits, of which we have been speaking. Take a test drive! Download the tool at: While you re at our website, take a look at the related topics on our blog and forum pages. Let us know your thoughts and questions. Thanks.