Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
mfisher Absent Member.
Absent Member.
3963 views

Calling JavaScript from COBOL

Jump to solution

I'm looking at the "Sample Web Browser Program" from the ACUCOBOL 9.2.2 "Programmer's Guide to the Internet". It compiles and works, but now I'd like to extend it with some event-driven interactions between JavaScript, VBScript, and COBOL.

Assume the following HTML5 document: 

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>HTML5 + JavaScript + VBScript Example</title>
<script type="text/vbscript"> Function vbFunction() document.write("vbFunction has been called") End Function </script> <script type="text/javascript"> function jsFunction() { document.write("jsFunction has been called") } </script> </head>
</body>
</body>
</html>

After the HTML5 page shown above has been loaded into the WEB-BROWSER control, is it possible for COBOL code to call the VBScript and JavaScript functions (vbFunction and jsFunction)?

A C# example that shows how it might be done in a pure .NET application is here:

http://msdn.microsoft.com/en-us/library/system.windows.forms.webbrowser.objectforscripting(v=vs.110).aspx

Microsoft's C# example relies on the ObjectForScripting property of the .NET Framework;s WebBrowser class. But I don't see any equivalent property exposed in AcuBench for the WEB-BROWSER control.

A related question is, how might JavaScript or VBScript that's running in the WEB-BROWSER control trigger an event that could then be handled by COBOL code? Say for example I wanted to do the following:

    • User clicks a button with an onclick attribute that specifies a JavaScript function (function1).
    • The JavaScript function raises some event (for example by changing the value of the <title> element?)
    • A COBOL procedure "somehow" handles the event, and reads a record from a Vision file
    • The COBOL procedure calls another JavaScript function (function2), passing the value of a COBOL field as a parameter

The point of this approach would be to allow the user interface to be written entirely in HTML5 + JavaScript and/or VBScript, while the COBOL program containing the WEB-BROWSER control would handle the IO with Vision files that reside in the Windows filesystem.

Any advice would be appreciated!

0 Likes
2 Solutions

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

RE: Calling JavaScript from COBOL

Jump to solution

The web-browser control is pretty limited, when you look at it's properties, the one that changes is the value, which is a URL. You may be able to get what you are looking for, by instead of using the web browser, using Internet Explorer as a .Net control. By using NetDefGen and IE you may be able to interact with JavaScript or VBScript and inquire on certain values which you could return to the COBOL program.

View solution in original post

0 Likes
Knowledge Partner
Knowledge Partner

RE: Calling JavaScript from COBOL

Jump to solution

You may not like my advice, but here it is anyway.

What you are proposing seems to me to be coupling the browser scripting for too closely with the containing application.  The result will most likely be brittle, and a difficult path for the future.

A more loosely coupled system would use web services (JSON or SOAP) to do the IO.  You can use Xcentrisity Business Information Server (BIS) to implement such web services in ACUCOBOL.  The product comes with a tutorial that describes creating web services.

Invoking web services from JavaScript is easily done with several readily available, widely used libraries; the best known is jQuery. 

"The point of this approach would be to allow the user interface to be written entirely in HTML5 + JavaScript..."

If you are anticipating implementing the UI entirely in JavaScript in HTML5, you really should consider jQuery, jQueryUI, and jTable.

[Disclaimer:  Our application's UI is entirely in HTML using BIS, but in a 'direct to browser' mode that I would now consider 'deprecated'.  Our UI predates jQuery and is quite tightly coupled to the underlying COBOL, though in a different way than you propose.  We are currently reworking hundreds of screens to move to a jQuery/web services approach.  Further disclaimer: I wrote the BIS tutorial so I am a bit biased!]

Tom Morrison
Hill Country Software


Tom Morrison
Consultant

View solution in original post

0 Likes
6 Replies
Micro Focus Expert
Micro Focus Expert

RE: Calling JavaScript from COBOL

Jump to solution

The web-browser control is pretty limited, when you look at it's properties, the one that changes is the value, which is a URL. You may be able to get what you are looking for, by instead of using the web browser, using Internet Explorer as a .Net control. By using NetDefGen and IE you may be able to interact with JavaScript or VBScript and inquire on certain values which you could return to the COBOL program.

View solution in original post

0 Likes
Knowledge Partner
Knowledge Partner

RE: Calling JavaScript from COBOL

Jump to solution

You may not like my advice, but here it is anyway.

What you are proposing seems to me to be coupling the browser scripting for too closely with the containing application.  The result will most likely be brittle, and a difficult path for the future.

A more loosely coupled system would use web services (JSON or SOAP) to do the IO.  You can use Xcentrisity Business Information Server (BIS) to implement such web services in ACUCOBOL.  The product comes with a tutorial that describes creating web services.

Invoking web services from JavaScript is easily done with several readily available, widely used libraries; the best known is jQuery. 

"The point of this approach would be to allow the user interface to be written entirely in HTML5 + JavaScript..."

If you are anticipating implementing the UI entirely in JavaScript in HTML5, you really should consider jQuery, jQueryUI, and jTable.

[Disclaimer:  Our application's UI is entirely in HTML using BIS, but in a 'direct to browser' mode that I would now consider 'deprecated'.  Our UI predates jQuery and is quite tightly coupled to the underlying COBOL, though in a different way than you propose.  We are currently reworking hundreds of screens to move to a jQuery/web services approach.  Further disclaimer: I wrote the BIS tutorial so I am a bit biased!]

Tom Morrison
Hill Country Software


Tom Morrison
Consultant

View solution in original post

0 Likes
mfisher Absent Member.
Absent Member.

RE: Calling JavaScript from COBOL

Jump to solution

That sounds like a reasonable approach. Thanks!

0 Likes
Knowledge Partner
Knowledge Partner

RE: Calling JavaScript from COBOL

Jump to solution

Here is an example of a page using jTable (which is built on jQuery), being fed data (JSON) by web service running on Xcentrisity BIS (RM/COBOL version).

Upcoming Chili Cookoffs


Tom Morrison
Consultant

mfisher Absent Member.
Absent Member.

RE: Calling JavaScript from COBOL

Jump to solution

Using web services as the glue would have been my first choice, but it was shot down as involving too many other departments outside our control. In strictly technical terms, what you proposed would be more maintainable. This is supposed to be a small one-off feature, but you know how that goes -- things take on a life of their own, and before long it proves to be a "brittle, and a difficult path for the future".

0 Likes
mfisher Absent Member.
Absent Member.

RE: Calling JavaScript from COBOL

Jump to solution

Only in Texas... 🙂

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.