Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE
brendang
New Member.
868 views

Help with XML

Jump to solution

 Hi

We have a windows forms payroll application, which uses classes and called programs (migrated from Net Express and all compiled as managed code), and using .idx data files.  We are using VC 2.3 and Visual Studio Community 2015.

We will soon have to start uploading XML files with employee information to an Irish government website, which will send XML files back as responses.  The XML files all have accompanying .xsd schema files.  The XML files could contain information for 1 employee, or a few thousand employees, so they could be bytes or mb in size.  Initially, we will be doing this manually by logging onto the website and manually selecting the file that has been created by our application.  We will get an XML file back and this will be processed into our application.  At a later date we have the option to automate the process into our application by integrating with the site's web services using SOAP.  These web services are defined in wsdl files.

For now, I am interested in the best coding approach to create and read in/validate/process the XML files.  Given that we have the .xsd files to hand, and may choose to implemnt the SOAP integration later, would it be best to use COBOL syntax, or .Net classes, or a mixture of both?  What is the best approach to write and validate XML files based on .xsd schemas?  If we use COBOL syntax, which would be better, XML Extensions or XML Syntax Extensions, and am I correct in thinking that XML Syntax Extensions is not allowed in classes, and does cbl2xml refer only to XML Syntax Extension?  If we choose .NET classes, which ones would be best.  Would stream-based or in-memory be better?  We have not before had to process in XML files, only write them, which we did using basic (non-XML) COBOl syntax.

I have read XML related posts on the forum but they do not answer all my questions.

Thank you for any help.

0 Likes
1 Solution

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

RE: Help with XML

Jump to solution

Unless I've missed a new feature, there is no LINQ support in COBOL. While it's possible to use the LINQ classes, LINQ itself is a collection of syntax languages to specific .NET languages, notably C# and VB.NET. The compiler translates that syntax into the appropriate method invocations.

Which .NET Framework XML technology is most appropriate depends very much on the particulars of the use case.

  • XML serialization lets a program convert an XML document into an object of a specific class that corresponds to that document type. It's most useful when there are only a few document types, they're relatively concise, and they rarely change. XmlSerializer is the main class.
  • DOM (Document Object Model) processing loads an entire XML document into a data structure, which can then be operated on in various ways. It too is appropriate for relatively small documents - loading a gigabyte-sized document into memory is not advisable. The XmlDocument class is the main one for DOM processing.
  • Forward-only parsers such as XmlReader are lightweight and fast. Since they process XML documents as streams, the program has to remember whatever state it needs - that is, what it's seen so far in the document. For creating documents, the corresponding class is XmlWriter.
  • XPath (using XPathDocument and XPathNavigator) is a language for extracting specific pieces of information from an XML document. It can easily get awkward to write and maintain.
0 Likes
5 Replies
lanter-edv_ch Outstanding Contributor.
Outstanding Contributor.

RE: Help with XML

Jump to solution
More than 10 years ago we wrote an application with a web service to handle the business logic with database access and several clients which call the web service. For data exchange between the web service and the clients we are using XML documents. For creating and reading the XML documents we are using .Net classes. We also wrote a little framework with methods like ‘GetXmlNodeAsString’, ‘GetXMlNodeAsDateTime’, ‘GetXMlNodeAsDecimal’, etc.; similar for write/create node. This is a very flexible solution, because there is no need to change a client if e.g. the web service writes a new sub-node which is used by another client.

Freundliche Grüsse
Werner Lanter
0 Likes
Knowledge Partner
Knowledge Partner

RE: Help with XML

Jump to solution

First, as a matter of disclosure, I am highly biased in favor of XML Extensions; check my profile if you are curious.  

From an architectural standpoint, I favor XML Extensions, because it promotes much looser coupling between the XML document(s) and the application.  Looser coupling allows you to limit the scope of changes to your application when the Irish government decides to create changes from year to year.  XML Extensions is essentially a CALL interface (XML Extensions 'statements' use the REPLACE mechanism to hide the CALL syntax and promote readability) that is used to export/import XML documents using standard COBOL data descriptions.  There are additional 'statements' that allow schema validation, etc.

On the other hand, XML Syntax Extensions tightly couple the XML document to the COBOL source program.  I am not extremely experienced with using XML Syntax Extensions, but it appears to me that even modest changes to an XML document might require extensive source modifications to the COBOL program, especially if one must maintain the ability to process multiple versions of the same document.  

Returning to XML Extensions, the main new technology that must be acquired for the developer is XSL - an XML-based transformation language.  In today's world, this is a good skill to have, because XML shows up just about everywhere, and XSL is a key piece of the XML data processing environment.  However, this is not a huge learning problem, because there exist several good development tools that allow you to create modestly complex XSL using a visual interface (WYSIWYG, drag-and-drop, etc).  

I urge you to continue to ask more questions on this thread, as you work through your decision.  I have personal experience with a similar reporting scheme required by the Internal Revenue Service in the US to report health insurance coverage.

Best regards,
Tom Morrison


Tom Morrison
Consultant

0 Likes
Highlighted
brendang
New Member.

RE: Help with XML

Jump to solution
If we go down the .NET classes route, what classes should we use for what we want to achieve? We will be validating/reading.creating XML's. It is unlikely we will have to edit an existing one - if something goes wrong in the process or a change is required then we will be creating a new file. Microsoft seems to recommend System.Xml.Linq if you are writing new code, ...and they list other processing options.

Thanks

Brendan
0 Likes
Micro Focus Expert
Micro Focus Expert

RE: Help with XML

Jump to solution

Unless I've missed a new feature, there is no LINQ support in COBOL. While it's possible to use the LINQ classes, LINQ itself is a collection of syntax languages to specific .NET languages, notably C# and VB.NET. The compiler translates that syntax into the appropriate method invocations.

Which .NET Framework XML technology is most appropriate depends very much on the particulars of the use case.

  • XML serialization lets a program convert an XML document into an object of a specific class that corresponds to that document type. It's most useful when there are only a few document types, they're relatively concise, and they rarely change. XmlSerializer is the main class.
  • DOM (Document Object Model) processing loads an entire XML document into a data structure, which can then be operated on in various ways. It too is appropriate for relatively small documents - loading a gigabyte-sized document into memory is not advisable. The XmlDocument class is the main one for DOM processing.
  • Forward-only parsers such as XmlReader are lightweight and fast. Since they process XML documents as streams, the program has to remember whatever state it needs - that is, what it's seen so far in the document. For creating documents, the corresponding class is XmlWriter.
  • XPath (using XPathDocument and XPathNavigator) is a language for extracting specific pieces of information from an XML document. It can easily get awkward to write and maintain.
0 Likes
brendang
New Member.

RE: Help with XML

Jump to solution

Hi

 

We are now at the stage in our development where we want to send SOAP messages from our Windows forms application to a government website and receive messages back in the process.

 

We are creating the actual XML use .NET classes, XMLDocument, etc.  For SOAP, we need to wrap the XML in an envelope, sign the message, and send to an endpoint.  To sign the message:

we need to extract a certificate from a .p12 file using an encrypted passord

add a binary security token

add a timestamp

add a digital signature, which involves extracting a private key from the cert.

 

After much trawling, it seems that .net does not have everything we need to achieve our goals.  Adding all the elements to the SOAP envelope should be fairly straightforward, it is creating them in the correct format that we are having difficulty with.

 

We are using Visual Cobol 2.3 for Visual Studio.  We were given sample code written in Java.  If we have to use Java then what version of Java do we download?  In other words, what version of Java is compatible with the version of VC we have?  Please nobody mention Eclipse, we would only be calling a relatively few lines of Java code to achieve what we want, surely this is achievable in VS.

 

Any help and other suggestions welcome.

 

Thank you

 

Brendan

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.