Hello!
So as I promised, let’s talk about Browser Script generation.
So first of all – to run a Browser Script you need to generate it. If you are developing application in Siebel Tools and want to test it you simply compile your configured object. For example you created a Browser Script on Applet. But before you can test its Browser Script you need to generate it. You can go to Views -> Options and choose Scripting tab to see where your Browser Scripts are generated. Simply go to this folder and delete all folders that have name like srf7845123265_753 or similar. Those folders hold the Browser Script JavaScript files that your Siebel Dedicated Client uses. When you delete all those folders you can compile your Applet. After compile you will see that Siebel Tools have created new folder there for you. It holds your Applets Browser Script. Now you can test it in Dedicated Client. If you want to compile or test more than one Browser Script (on different objects) then simply delete all folders and compile both objects. If you want that your Siebel Dedicated Client has all the latest Browser Scripts then simply get the last folder from your server (depending on architecture of project it can be on different places), and srf from server so you will have latest full compiled definitions.
All in all it is not too hard to understand this, but in while when you work with Browser Scripts you will come arose some thing that dint goes in any kind of logic. For example that version with two Browser Scripts on different objects needs to be tested. You delete all folders then compile both objects and test them. Everything seems OK. But then you decide to change something in one object Browser Script and then you just compile it. What happens? Well you will never actually know. It can create new folder with only this object Browser Script and then Siebel Dedicated Client will use only this. It can do nothing to folders and then the new changes will not work. It could just update the particular Browser Script in already existing folder. That way I tell – before compile Browser Scripts delete its folders.
Another big thing with Browser Scripts that makes them so painful is that they cannot be debugged. So forger about putting breakpoints in Browser Script code, they won’t work. So how we can tell where there are some errors? There is little way I have encountered. First Browser Script is JavaScript file that runs. So sometimes when JavaScript doesn’t work in Internet Explore you will see a triangle and explanation mark in lower left corner of browser. Simply click it and read the error. Maybe it will help you. Another way is to putt alert messages in the code to see what steps are done. Like you have 100 lines of code and you putted alert messages in each 25 lines (4 in all). So when you test application and three messages shows but last one not you know that error is between lines 75-100. Of course you need to put alerts in code in some logic way not just depending on count of line. For example to check witch steps of code are running witch not. To test some variables that you think didn’t populate simply output it in alert message to see them. Some times Browser Script will throw its own error message; most likely it will tell “undefined” usually it means that there are some syntax errors in code. For example you defined variable, but when you use it you misspelled the name of it by one character.
So all in all this is most likely some of core things about Browser Scripts. Sorry if I dint put some code in, but as I understand if you read this you know how to program a code. And as Siebel support say try to avoid any kind of scripting and use configuration to implement your functionality.
No comments:
Post a Comment