My RAMP application works in designer mode
but not in end user mode with an error "NL runtime manager outer wrapper
on vf_sy120.htm". What could be the possible cause of this?
| Date: |
17 May 2007 |
| Product/Release: |
Visual LANSA Framework - RAMP |
| Abstract: |
How to detect Javascript errors
in RAMP applications? |
| Submitted By: |
LANSA Technical Support |
Problem:
When running a RAMP application it works in
Framework Designer mode (e.g. UF_DESGN) but not in Framework End User mode
(e.g. UF_EXEC).
It also produces an error in x_err.log:
==========================
Component : VF_SY120
NL runtime manager outer wrapper
Line : 608
Message : Error Code = -1
Routine : Dispatch_Component_Manager
==========================
Is there a way to check what's the possible cause of this?
Possible Cause:
This could be an indication of some javascript syntax errors.
RAMP JavaScripts are executed two completely different ways
When you execute RAMP scripts as a DESIGNER, the JavaScript comes
from the 'Nodes' XML (eg: My_Nodes.XML).
Individual
RAMP scripts are dynamically loaded and executed from this
file. This is why you change your script and it executes
immediately.
When
executed as an END USER (in Windows or on the Web) the
JavaScript comes from a 'big' .JS files created when the
Framework was saved (eg:
My_Nodes_6C8F62620CB74C2893B4EFF7E23CD393.js).
These are the RAMP script files that you deploy.
All the scripts within a 5250 session (identified in this example
by the GUID 6C8F62620CB74C2893B4EFF7E23CD393) are defined into
this 'big' file and they are all loaded in one hit.
This is done because it produces much
better execution time performance than the dynamic loading
model that is used for designers.
This performance benefit of this model creates 2 possible issues
you need to be aware of:
- The
JavaScript in XML file and in the .JS files may be different.
What you test and what you deploy may not be the same. The
EPC804 version of the VLF will warn you if this happens. Prior
to EPC804 you should check that your nodes XML file and your
'big' JS file(s) have date/time stamps that are within a few
seconds of one another.
- Untested or unused scripts that contain syntax errors may be okay
during development, but will produce execution time errors.
Problem 2 is more complicated - How to locate untested or unused
scripts that contain JavaScript syntax errors
Say you have a script named BUTTON_SCRIPT_7 and you accidentally
put a syntax error in it.
You never test or use BUTTON_SCRIPT_7 during development.
The syntax problem will only be detected when BUTTON_SCRIPT_7 is
loaded, so you don't notice the problem.
BUTTON_SRIPT_7 then gets saved into the 'big' .JS file used at execution
time.
When you start up your RAMP application as an END USER, the 'big'
.JS file will not load properly because BUTTON_SCRIPT_7 is
syntactically invalid JavaScript.
Your RAMP application fails to start.
Solution - Do a test load of your 'big' .JS file
If your scripts work during development, but you get an error
when executing them in end user mode, then you should try this
test.
In your LANSA partition execute directory make a small file that
contains this HTML. The script src should be pointing at your
nodes.js file:
<html>
<head>
<script src="My_Nodes_6C8F62620CB74C2893B4EFF7E23CD393.js">
</script>
</head>
<body>
<p>TEST</p>
</body>
</html>
Save this file as (e.g. test.htm) and open this HTML file in Internet Explorer.
If there is a JavaScript syntax error in your 'big' JS file (eg:
My_Nodes_6C8F62620CB74C2893B4EFF7E23CD393.js) then you should
see an error message like this example.

This assumes that you allow JS errors to display, which is an IE
browser configuration setting you should check.
Working with the line number, and by looking at the content of the
'big' JS file, you should be able to locate the syntax error.
Go back to the Visual LANSA Framework RAMP Tool, correct the syntax error, then save your
Framework to create a new 'big' JS file.
Note: You might have more than one syntax error, so keep doing this
check until no errors are displayed.
|