Search

Folks, I am looking to migrate a few legacy debt collection applications built using InterSystems Cache to AWS. Does anyone here have any experience, ideas and best practices on migrating Cache products to the public cloud? Regards Sudarshan +1-917-685-3551 AWS offers EC2, and it will be just virtual machines. And it will be possible to migrate any of your instances quite easy, if you would choose the same environment. If you have windows on your server, you can have Windows there as well. It's the easiest way. You would need to install the same version of the InterSystems platform you use, and repeat the configuration, copy necessary information and that's it. But for sure, could be some other options. But AWS also suppose support for containers, this could be more difficult. And the best would be if you would use IRIS. I can help with this migration if you wish.

Hey Developers, Planning to attend the Focus Sessions of InterSystems Virtual Summit 2021? Don't miss the session dedicated to InterSystems Developer Community, Open Exchange & Global Masters! ⚡️ "Win. Win. Win with InterSystems Developer Ecosystem" VSummit21 session ⚡️ 🎁 Note: All session attendees get a special prize. Speakers: 🗣 @Anastasia.Dyubaylo, Community Manager, InterSystems 🗣 @Lena.Evsikova, Product Owner of InterSystems Open Exchange🗣 @Olga.Zavrazhnova2637, Customer Advocacy Manager, InterSystems Learn how to succeed with the InterSystems Developer Community, Global Masters gamification hub, and Open Exchange application gallery. Interests: Developer Experience, InterSystems IRIS, User Communities Our Focus Sessions are available on-demand for viewing from Wednesday, October 27! So! Join our session to enjoy the full experience of InterSystems Technology and our Ecosystem for Developers! Looking forward to it!! I will be there! @Olga.Zavrazhnova2637@Lena.Evsikova @Anastasia.Dyubaylo Just watched your presentation. It was really GREAT !!You raised the level of presentation significantly.The most attractive presentation for me so far.It will be hard to top you.CONGRATULATIONS ! So happy to hear that, Robert! Thank you! I completely agree with @Robert.Cemper1003! Great job highlighting the D.C., OEX and Global Masters!! Thank you, Robert! So happy to hear such feedback 😊 Thank you, Ben ☺️ Very good presentation. They are a true trio of pocker aces to win And all the crew that are in the same ship

Hey Community! New video is already waiting on InterSystems Developers YouTube: ⏯ Introducing the InterSystems IRIS Smart Factory Starter Pack for Manufacturing See how InterSystems IRIS® data platform and the Smart Factory Application Starter Pack enable manufacturers to fast-track their smart factory initiatives. The package combines operational technology systems and real-time signals from the shop floor with enterprise IT and analytics systems, enabling manufacturers to improve quality and efficiency, respond faster to events, and predict and avoid problems before they occur. Presenters: 🗣 @Joseph.Lichtenberg, Director, Product and Industry Marketing, InterSystems 🗣 @Marco.denHartog, Chief Technology Officer, IT Visors🗣 Marcel Artz, Chief Information Officer, Vlisco Enjoy and stay tuned!

November 19, 2021 - Advisory: Apache Web Server provided with InterSystems kits – Vulnerability reports InterSystems kits include an Apache web server, which provides a convenient way for customers to interact with the Caché/IRIS Management Portal without needing to install an external web server; however, this web server should never be used for production instances, and customers must install a web server that fits their specific needs and security/risk requirements. Recent tests have noted some security issues with the currently included Apache web server. Because this is a third-party technology that InterSystems does not control, InterSystems recommends installing a web server version directly obtained from Apache or another third party and disabling the included Apache web server. Our product documentation includes instructions on how to disable the web server provided with our kits. In addition, Apache also offers uninstall instructions that can be found on the Apache website. InterSystems plans to include a more recent version of the Apache web server in upcoming releases. Similar to the current version, this version also cannot be used for production instances. In future releases of our products, InterSystems will not ship or install any web server; we will provide further updates with the specifics of our plans. We have always used independent web servers for production. However, with the release of container deployment, can I get clarity on the webgateway container provided by ISC is NOT affected by the same vulnerabilities? I understood this to be a full apache instance with modules pre-installed. If so, are there any recommended practices one should use for this container in a production environment? Hi @Trevor.Strong The container image simply installs the standard Apache package in the container and adds the CSP add-on. For any update on the Apache web server we should all keep an eye on https://www.cvedetails.com/product/66/Apache-Http-Server.html?vendor_id=45 and consider patching/upgrading/re-building as necessary and according to the security policies and best practices of the organizations we work for. HTH

Hi Community, New video is already on InterSystems Developers YouTube! Learn about the easy process of migrating to InterSystems IRIS: ⏯ Join Us on a Journey from Caché/Ensemble to InterSystems IRIS 🗣 Presenter: @Jeffrey.Morgan, Sales Engineer, InterSystems Enjoy and stay tuned!

Hey Community, We're excited to announce that Community webinars are back! Let us invite you all to @Ron.Sweeney1582's webinar on Scaling InterSystems FHIR Server on Amazon Web Services with ECP. Join this webinar to make a technical deep dive, see a demonstration, and benchmark horizontal scaling InterSystems FHIR Server on Amazon Web Services with Enterprise Cache Protocol (ECP). ⏱ Date & Time: Thursday, August 18, 8 AM ET | 2:00 PM CEST👨‍🏫 Speaker: @Ron.Sweeney1582, Full Stack Architect at Integration Required About Integration Required: We are a full-stack technical delivery team for your InterSystems® workloads, tailored to meet the requirements of your security posture and organizational deployment standards. With a decade of InterSystems® partnerships and rigorous adherence to customer satisfaction, we are trusted to best practice. So... Don't miss this opportunity to learn more about scaling FHIR, ECP and AWS and how to mix it all! >> REGISTER HERE << Hi Devs, Don't miss the upcoming webinar with @Ron.Sweeney1582! Already 27 registered people. 😎 Registration continues >> click here << Hurry, only a week left! 🔥 Developers, The upcoming webinar will be tomorrow! Don't miss this opportunity to learn more about scaling FHIR, ECP and AWS and how to mix it all! For registration >> click here << Hey Community, The webinar will start in 15 mins! Please join us in Zoom. Or enjoy watching the live stream on YouTube: https://youtu.be/DBGvt0jd4yI Hi. I fell asleep before it started :) Is there a recording available? do we hv replay for this? Thx! Hi Michael, Anastasia mentioned rerun is at: https://youtu.be/DBGvt0jd4yI Hey everyone! The recording of this webinar is available on DC YouTube: ▶️ [Webinar] Scaling InterSystems FHIR Server on Amazon Web Services with ECP Big applause to our awesome speaker @Ron.Sweeney1582 👏👏👏 And thanks everyone for joining! Really enjoyed the webinar @Ron.Sweeney1582 Great content, insights and results, and thanks for the mentions

Have you ever needed to find a record for a particular person in your inbound data stream? Searching messages will enable you to find messages using an array of search capabilities.Searching Messages Using the Message ViewerSearching Messages Using the Message Viewer introduces the Message Viewer and details how to access it,and describes the process for modifying the message list display. Learn More. Nice little course, thanks!

Learn how to push an application to both an iOS and an Android device.Configuring a Mobile Device for Application DeploymentThis course discusses the process needed to push an application to both an iOS and Android device. Learners can choose which device they would like to learn about, or they can step through both to understand the settings and steps needed to push to both device types. Learn More.

Learn the basics about HealthShare Information Exchange, the architecture and common ways it is used.Find out how to perform a patient search, identify the main parts of HealthShare Information Exchange and the main purposes of each. Learn More.*This course is available to our HealthShare customers only.

Learn why and when to use FHIR in your applications, common use cases for it, the general architecture of FHIR data, and the tools available to you in InterSystems HealthShare Health Connect. Learn More. Thank you for the online course! Very much needed.The course videos below are not available. Getting an error "No playable video sources found":WHAT IS FHIR?FHIR VS. HL7V2, HL7V3, AND CDAFHIR ARCHITECTUREAlso, it would be nice to get access to the custom code show in "FHIR IN HEALTHSHARE DEMONSTRATION", specifically, "Summit.BPL.V2ToFHIR." I'm sure many developers would like to know how to convert good old HL7v2 messages to FHIR resources using HealthConnect. Video's are not available. We've re-uploaded the videos and are working again. Please try the course again and let us know if there any further problems.

Are you going to be building an integration with Ensemble or HealthShare? Take the following course to learn about the core architecture in building an integration, the parts and pieces involved and the most common ways that data flows through that architecture.Integration Architecture: Ensemble and HealthShareLearn about the basic architecture of InterSystems' solution for integration. This course is for people who have purchased either Ensemble and HealthShare. This course covers the main parts of integration, each part's function and how data flows through that architecture. Learn More.

Hi! Want to share with you code snippet of try catch block I usually use in methods which should return %Status. { try { $$$TOE(sc,StatusMethod()) } catch e { set sc=e.AsStatus() do e.Log() } Quit sc } Here $$$TOE is a short form of $$$TROWONERROR macro. Inside macro StatusMethod is any method you call which will return %Status value. This value will be placed into sc variable. In case of sc contains error execution will be routed to try catch block. You can wrap any Status methods calls in your code if you need to catch the errors coming from them. In try catch block I place my logic and have to mandatory calls: s sc=e.AsStatus() to get the status of error. D e.Log() - to place all the stack of error to standard Application Error log which you can find in Management portal on this page: http://localhost:57772/csp/sys/op/UtilSysAppErrorNamespaces.csp?$NAMESPACE=SAMPLES&Recent=1 How do you handle errors in your COS logic? I often do this too, I think this sort of pattern is a good way to make the error handling simple and consistent. I'm not really a fan of the status codes. They seem like a legacy item for the days prior to try/catches when traps were used. Having to maintain code to handle possible exceptions AND "errors" means more control flow to check and handle problems through the various levels of code.Say that code above is within a method that's within another method that's called from the main part of the program. Now, you need three levels of try/catches. That's a lot of extra lines of code (code smell), lost errors and performance degradation.Instead, I encourage my developers to use the fail fast methodgy. We use try/catches as high as possible in the code or when absolutely necessary, like when something is prone to exceptions but shouldn't stop the overall program from running. I agree with you. As mentioned it is an option if you need to use %Status as a method result. And what about e.Log() - do you use it to log errors or use something else? Status codes still have a place along side of Try/Catch in my opinion. They really only serve to indicate the ending state of the method called. This is not necessarily an error. I agree that throwing an exception for truly fatal errors is the best and most efficient error handling method. The issues is what does "truly fatal" mean? There can be a lot of grey area to contend with. There are methods where the calling program needs to determine the correct response. For example take a method that calculates commission on a sale. Clearly this is a serious problem on a Sales order. However, it is less of an issue on a quotation. In the case of the latter the process may simply desire to return an empty commissions structure.Placement of try/catch blocks is a separate conversation. Personally I find using try/catch blocks for error handling to be clean and efficient. The programs are easier to read and any recovery can be consolidated in one place, either in or right after the catch. I have found that any performance cost is unnoticeable in a typical transactional process. It surely beats adding IF statements to handle to handle the flow. For readability and maintainability I also dislike QUITing from a method or program in multiple places. So where is the "right" place for a try/catch? If I had to pick one general rule I would say you should put the try/catch in anyplace where a meaningful recovery from the error/exception can be done and as close to the point where the error occurred as possible. I the above example of a Commission calculation method I would not put a try/catch in the method itself since the method can not perform any real recovery. However I would put one in the Sales order and Quotation code.There are many methods to manage program flow under error/exception situations; Try/Catch, Quit and Continue in loops are a couple off the top of my head. Used appropriately they can create code that is robust, readable and maintainable with little cost in performance. I agree with both Nic and Rich.The issue with e.Log() is that it clutters up the error log with repetitive entries, each subsequent one with less detail than the prior. The same thing happens in Ensemble when errors bubble through the host jobs.The trick here is knowing when to log an error verses when to just bubble it up. Using Nic's method we lose the context of the stack since the log isn't written until the entry method with the Try/Catch. Using your method we get noise in the logs, but at least the first one has the detail we'll need.I believe the root problem here is re-throwing the status. An exception should represent something fatal and usually out of the applications control (e.g. FILEFULL) while a %Status is a call success indicator. To that end your code could be refactored to just Quit on an error instead of throwing it. That way a single log is generated in the method that triggered the exception and the stack is accurate.However this doesn't work well in nested loops. In that case a Return would work unless there is a cleanup chore (e.g. releasing locks, closing transactions, etc). I haven't come up with a pattern for nested loops that doesn't clutter up the source with a bunch of extra $$$ISERR checks that are easily missed and lead to subtle bugs.Personally I use your style without logging because:Every method uses the same control structureWorks with nested loops without extra thoughtCan ignore errors by simply invoking with Do instead of $$$TOE/$$$ThrowOnErrorCleanup code is easy to find or insertUsing ByRef/Output parameters makes it trivial to refactor to return more than one valueI do lose the ability to see an accurate stack trace but most of the time the line reference in the error is enough for me to quickly debug an issue so it is an acceptable trade-off. Only in the most trivial methods is the Try/Catch skipped.All that said Nic's style is a solid approach too. By removing a bunch of boilerplate Try/Catch code it lets the programmer focus on the logic and makes the codebase much easier on the eyes. We use various methods and macros to log exceptions, it just depends on the situation. I see where you are coming from with having a status code returned to notify a problem exists. Personally, I'd calculate comissions in a seperate single responsibility class that extends an abstract class for interface segregation. That class implements three public methods: Calculate(), HasError(), GetError()//calculate then commission: Set tCommission = tUsedCarCommission.Calculate()If tUsedCarCommission.HasError() //log the error or do something with it It's very similar to what you'd do with traditional status types but without having to deal with passing in references. Also, IMO, it's very clear what's going on if the commission has an error. OK. But how do you call methods which return %Status?Do you raise Error? Or you check Error status with if? Or do you ignore status at all? I will leave the logging issue alone as I don't see it as being the main point of the example. It could also be a thread by itself.The issue of using a bunch of $$$ISERR or other error condition checks is exactly why I like using throw with try/catch. I disagree that it should only be for errors outside of the application's control. However it is true that most of the time you are dealing with a fatal error. Fatal that is to the current unit of work being performed, not necessarily to the entire process.I will often use code likeset RetStatus = MyObj.Method() throw:$$$ISERR(RetStatus) ##class(%Exception.StatusException).CreateFromStatus(RetStatus)The post conditional on the throw can take many forms, this is just one example.Where I put the Try/Catch depends on many factors such as:Where do I want recovery to happen?use of the method and my code readability and maintainability of the code...I the case of nested loops mentioned I think this is a great way to abort the process and return to a point, whether in this program or one farther up the stack, where the process can be cleanly recovered or aborted. Most of my methods look like this: Method MyMethod() As %Status { // Initialization - note locking and transactions only when needed Set sc = $$$OK Lock +^SomeGlobal:5 If '$TEST Quit $$$ERROR($$$GeneralError,"Failed to obtain lock") Try { TSTART // When error is significant $$$ThrowOnError(..SomeMethod()) // When error can be ignored Do ..SomeMethod() // When only certain errors apply Set sc = ..SomeMethod() If $$$ISERR(sc),$SYSTEM.Status.GetErrorText(sc)["Something" $$$ThrowStatus(sc) TCOMMIT } Catch e { TROLLBACK Set sc = e.AsStatus() } Lock -^SomeGlobal Quit sc } Well, I think a major question is: What do you use to return runtime information to your caller when you implement your own code? Do you return a %Status object, or something similar, or do you throw exceptions and don't return anything.Most code snippets I have seen here make use of try/catch, but do return a status code itself. Personally, I prefer to use try/catch blocks and throw errors when I encounter issues at runtime. The try/catch philosophy is optimized for the case that everything goes well and exceptions are the, well, exception. Handling a status object is not as clean from a code maintenance perspective (more lines of code within your logic), but allows you to handle multiple different scenarios at once (it was okay/not okay, and this happened...)Obviously, this is my personal preference. What do you do when you need to cleanup things like locks? Put the unlock code both in the Catch and before the Quit? Well, that depends on where you did take the lock.In your previous example you take a lock right before the try block, so you can release it directly after the try/catch block.If you take a lock in your try block, you have to put the unlock code both in the catch block and at the end of the try block. I would not place the unlock code outside of the try/catch block. This is a case where a try/catch/finally construct would definitely help, as you could place the unlock code in the finally block. Other than locks, there are a few other cases where cleanup may be needed whether or not something goes wrong:Closing SQL cursors that have been openedEnsuring that the right IO device is in use and/or returning to the previous IO redirection state.There are probably more of these too.Here's the convention we use for error handling, logging, and reporting in InSync (a large Caché-based application):We have TSTART/TCOMMIT/TROLLBACK in a try/catch block at the highest level (typically a ClassMethod in a CSP/Zen page). There isn't much business logic in here; it'll call a method in a different package.If anything goes wrong in the business logic, an exception is thrown. The classes with the business logic don't have their own try/catch blocks unless it's needed to close SQL cursors, etc. in event of an exception. After the cleanup is done, the exception is re-thrown. (Unfortunately, this means that cleanup code may be duplicated between the try and catch blocks, but there's typically not too much duplication.) The classes with business logic also don't have their own TSTART/TCOMMIT/TROLLBACK commands, unless the business logic is a batch process in which parts of the process may fail and be corrected later without impacting the whole thing; such a case may also call for a nested try/catch to do the TROLLBACK if something goes wrong in part of the batch. In this case the error is recorded rather than re-throwing the exception.We have our own type of exception (extending %Exception.AbstractException), and macros to create exceptions of this type from:Error %Status codesError SQLCODEs and messagesSQLCODE = 100 can be treated as an error, "alert", or nothing.Other types of exceptionsExceptions of our custom type can also be created to represent a general application error not related to one of those things, either a fatal error, or something the user can/should fix - e.g., invalid data or missing configuration.The macros for throwing these exceptions also allow the developer to provide a localizable user-friendly message to explain what went wrong.When an exception is caught in the top level try/catch (or perhaps in a nested try/catch in a batch process), we have a macro that logs the exception and turns it into a user-friendly error message. This might just be a general message, like "An internal error occurred (log ID _______)" - the user should never see <UNDEFINED>, SQLCODE -124: DETAILS ABOUT SOME TABLE, etc.Our persistent classes may include an XDATA block with localizable error messages corresponding foreign and unique keys in the class and types of violations of those keys. For %Status codes and SQLCODEs corresponding to foreign/unique key violations, the user-friendly error message is determined based on this metadata.Logging for these exceptions is configurable; for example, exceptions representing something the user can/should fix are not logged by default, because they're not an error in the application itself. Also, the log level is configurable - it might be all the gory detail from LOG^%ETN, or just the stack trace. Typically, verbose logging would only be enabled system-wide briefly for specific debugging tasks. For SQL errors, the SQL statement itself is logged if possible.I thought this convention was too complicated when I first started working with it, but have come to see that it is very elegant. One possible downside is that it relies on a convention that any method in a particular package (InSyncCode, in our case) might throw an exception - if that isn't respected in the calling code, there's risk of a <THROW> error.I mentioned the InSync approach previously on https://community.intersystems.com/post/message-error-csppage . Unfortunately, it's coupled with several parts of the application, so it'd be quite a bit of work to extract and publish the generally-applicable parts. I'd like to do that at some point though. >$SYSTEM.Status.GetErrorText(sc)["Something" Would not always work correctly in applications with users requesting content in several languages (for example web app). Why not use error codes? If $SYSTEM.Status.GetErrorCodes(sc)[$$$GeneralError $$$ThrowStatus(sc) Timothy! Thanks for sharing this!It' can be a standalone post as "Error and resource handling in large Caché ObjectScript project".Thank you! Agreed - GetErrorCodes() is the right thing to do from an I18N perspective. For more advanced error analysis, such as conversion of error %Status-es into user-friendly messages (as I described in another comment), $System.Status.DecomposeStatus will provide the parameters of the error message as well. These are substituted in to the localizable string. For example, here's a foreign key violation message from %DeleteId on a system running in Spanish: INSYNC>Set tSC = ##class(Icon.DB.CT.TipoDocumento).%DeleteId(50) INSYNC>k tErrorInfo d $System.Status.DecomposeStatus(tSC,.tErrorInfo) zw tErrorInfo tErrorInfo=1 tErrorInfo(1)="ERROR #5831: Error de Foreign Key Constraint (Icon.DB.CC.AllowedGuaranteeTypes) sobre DELETE de objeto en Icon.DB.CT.TipoDocumento: Al menos existe 1 objeto con referencia a la clave CTTIPODOCUMENTOPK" tErrorInfo(1,"caller")="zFKTipoDocDelete+4^Icon.DB.CC.AllowedGuaranteeTypes.1" tErrorInfo(1,"code")=5831 tErrorInfo(1,"dcode")=5831 tErrorInfo(1,"domain")="%ObjectErrors" tErrorInfo(1,"namespace")="INSYNC" tErrorInfo(1,"param")=4 tErrorInfo(1,"param",1)="Icon.DB.CC.AllowedGuaranteeTypes" tErrorInfo(1,"param",2)="Icon.DB.CT.TipoDocumento" tErrorInfo(1,"param",3)="DELETE" tErrorInfo(1,"param",4)="CTTIPODOCUMENTOPK" tErrorInfo(1,"stack")=... The "param" array allows clean programmatic access to the details of the foreign key violation, independent of language. Of course, these level of detail in these error messages may be subject to change across Caché versions, so this is a *great* thing to cover with unit tests if your application relies on it. I prefer doing this more correctly using the right API for matching status values: If $system.Status.Equals(sc,$$$ERRORCODE($$$GeneralError),$$$ERRORCODE($$$MoreSpecificStatusCode),...) { // Handle specific error(s) } The use of `'` can result in unexpected behaviour when you are checking for a 4 digit code, but are handling a 3 digit code... Note that it's also safer to wrap status codes in `$$$ERRORCODE($$$TheErrorCode)`, but that may not be necessary depending on the specific context. A rather subtle point that I haven't seen discussed here is actually about how TSTART/TCOMMIT/TROLLBACK should be handled when triggering a TROLLBACK from code that may be part of a nested transaction. Given that a lot of the code I write may be called from various contexts and those calling contexts may already have open transactions, my preferred transaction pattern is as follows: Method SaveSomething() As %Status { Set tStatus = $$$OK Set tInitTLevel = $TLevel Try { // Validate input before opening transaction so you can exit before incurring any major overhead TSTART // Do thing 1 // Do thing 2 // Check status or throw exception TCOMMIT } // Handle exception locally due to local cleanup needs Catch ex { Set tStatus = ex.AsStatus() } While ($TLevel > tInitTLevel) { // Only roll back one transaction level as you make it possible for the caller to decide whether the whole transaction should be rolled back TRollback 1 } Quit tStatus } (Edited for formatting.) What's the advantage of using $$$ERRORCODE macro? ^%qCacheObjectErrors global contains the same values.

Announcing the Custom Business Components learning path! This learning path is designed for software developers who need to build custom business components for their productions.The learning path includes the following courses: 1. Building Custom Ensemble Messages2. Building Custom Business Operations3. Building BPL Business Processes4. Building Custom Business Services 5. Coming Soon: Building Custom Business ServicesAccess the learning path. We're really excited about this learning path as its something many of you have asked for! Have you taken the Building and Managing HL7 Productions classroom course but now need to create custom components? This is a great next step! As always, please let us know if you have other suggestions for courses, learning paths, or best practices that we can incorporate in future learning content.

Hello all! As we ObjectScript developers have been experiencing, preparing an environment to run CI related tasks can be quite the chore. This is why I have been thinking about how we could improve this workflow and the result of that effort is [IRIS-CI](https://openexchange.intersystems.com/package/iris-ci). See how it works [here](https://imgur.com/N7uVDNK). ### Quickstart 1.Download the image from the Docker Hub registry: ``` docker pull rfns/iris-ci:0.5.3 ``` 2. Run the container (with the default settings): ``` docker run --rm --name ci -t -v /path/to/your/app:/opt/ci/app rfns/iris-ci:0.5.3 ``` Notice that volume mounting to `/path/to/your/app?` This is where the app should be. And that's it: the only thing required to start running the test suites is the path of the application. Also, since this is supposed to be a ephemeral and run-once container, there's no need to keep it listed after executing it, that's why there's the `--rm` flag. ### TL;DR; If you want an example on how to how use it: Check the usage with my another project [dotenv](https://github.com/rfns/dotenv/blob/master/.github/workflows/ci.yml). ### Advanced setup Some projects might need sophisticated setups in order to run the test suites, for such circunstances there's two customization levels: 1. Environment variables 2. Volume overwrite ### Environment variables Environment variables are the most simple customization format and should suffice for most situations. There's two ways to provide an environment variable: * `-e VAR_NAME="var value"` while using `docker run`. * By providing a .env file by mounting an extra volume for `docker run` like this: `-v /my/app/.env:/opt/ci/.env`. > NOTE: In case a variable is defined in both formats, using the `-e` format takes precedence over using a `.env` file. ### Types of environment variables * Variables prefixed with `CI_{NAME}` are passed down as `name` to the installer manifest. * Variables prefixed with `TESPARAM_{NAME}`are passed down as `NAME` to the unit test manager's UserFields property. * `TEST_SUITE`and `TEST_CASE` to control where to locate and which test case to target. Every variable is available to read from the `configuration.Envs` list, which is [passed](https://github.com/rfns/iris-ci/blob/master/ci/Runner.cls#L6) [down](https://github.com/rfns/iris-ci/blob/master/ci/Runner.cls#L53) through `Run` and `OnAfterRun` class methods. If `TEST_CASE` is not specified then the `recursive` flag will be set. In a project with many classes it might be interesting to at least define the `TEST_SUITE` and reduce the search scope due to performance concerns. ### Volume overwrite This image ships with a default installer that's focused on running test suites. But it's possbile to overwrite the following files in order to make it execute different tasks like: generating a XML file for old Caché versions. * `/opt/ci/App/Installer.cls` * `/opt/ci/Runner.cls` For more details on how to implement them, please check the default implementations: [Installer.cls](https://github.com/rfns/iris-ci/blob/master/ci/App/Installer.cls) [Runner.cls](https://github.com/rfns/iris-ci/blob/master/ci/Runner.cls) > TIP: Before overwriting the default Installer.cls check if you really need to, because the current implementation [also allows to create configurated web applications.](https://github.com/rfns/iris-ci#using-the-default-installer-manifest-for-unit-tests) EDIT: Link added.

Hello Developer Community! We are looking to better understand how our users use the Documentation. If you have a few minutes, please fill out this quick survey - https://www.surveymonkey.com/r/HK7F5P7! Feedback from real users like you in invaluable to us and helps us create better product. Your feedback can go further than the survey - we would love to interview you about your experience, just indicate in the survey that you’re open to talking to us! Thank you so much! If you have any questions, please contact me at Ksenia.samokhvalova@intersystems.com I look forward to hearing from you! Ksenia Ksenia SamokhvalovaUX Designer | InterSystemsKsenia.samokhvalova@intersystems.com