Debugging is the process of finding and resolving defects or problems within a computer program that prevents the correct operation of computer software or a system.
ISCLOGs are a useful debugging tool provided with IRIS that can help you troubleshoot many different issues. For more information about creating these logs, please see the following IRIS documentation: "Logging".
Many programming languages use the try-and-catch construct to handle runtime errors gracefully. If the code within the try block encounters an error, it will throw an exception to the catch block, where the error handling occurs.
Embedded Python has been around for a while. You probably followed the tutorials and learned about it. However, if you've tried to combine Python and ObjectScript in real development work, you probably ran into situations where you get an error message like this:
Is there a general way to set a variable XYZ equal to the text of thecode line being executed now? Debugger or production. For example, for a code below if code is currently assigning a to 1, XYZ would be equal "S a=1". The same question about a variable containing current routine name.
If anyone has experience debugging Embedded Python or has insight into why an ObjectScript method when called from a Python method would not work but would work when called directly via ObjectScript or in a Python shell, your help would be appreciated!
We have an ObjectScript ClassMethod called GetTemplateString() which takes in a templateName of String type and uses the template name to get the template object, access the Code, and read the code into a templateString. The string version of the Code is returned.
I have an operation using $ZF this operation ran and did not error but the job has been active and it can not be stopped I have tried stopping it from the front end and through the terminal using ##class(ENSLIB.Job).%New() Stop method. Now my production will not update even if I add a new item to the production I cannot update the item is there a way to force stop this job.
We are using a DTL transformation to take HL7 and transform into custom XML. But the nodes in the resulting XML are appearing out of sequence - and therefore failing validation against the schema.
The XSD schema for the XML looks fine when imported into Ensemble: root node in the XSD looks like this: And shows in Ensemble like this:
I need to see the full SMTP trace when a %Net.SMTP attempts to send an email to troubleshoot an issue. As far as I know, the only way to get that is to uncomment line 192 in the %Net.SMTP class.
//:#define SMTPTRACE
I've done this in the past by giving myself the %DB_IRISSYS role, so I tried that. That database is also not mounted as read-only.
Developers have Ensemble installed locally on their laptops - code will be developed locally then deployed to integration, test/UAT and ultimately production servers in due course.
One of the other applications we are developing around happens to utilise an Iris desktop client to a remote Iris server. We want to have the application available on the developers laptops alongside the local Ensemble instance.
We are calling a REST web-service from Ensemble using EnsLib.HTTP.OutboundAdapter and redefining the adapter class to set custom headers as described by @Eduard Lebedyuk here: How to set Content-Type
I'm diving deeper into Caché ObjectScript and would love to open a discussion around the most useful tips, tricks, and best practices you’ve learned or discovered while working with it.
Whether you're an experienced developer or just getting started, ObjectScript has its own set of quirks and powerful features—some well-documented, others hidden gems. I’m looking to compile a helpful set of ideas from the community.
We are using a DTL transformation to take HL7 and transform into custom XML (XML is a virtual document, held in an EnsLib.EDI.XML.Document object). The schema specifying the format of the XML says one element should occur no more than 24 times (maxOccurs="24" in the XSD schema). However, the transformation to produce one such element always produces 24 elements, all but the last one blank, when tested stand-alone.