@Gautam Rishi , I see it contains module.xml in the root. So it is prepared to act as a ZPM module.
You probably can install it as:
USER>zpm "load https://github.com/GendronAC/InterSystems-UnitTest-Mocking"
- Log in to post comments
@Gautam Rishi , I see it contains module.xml in the root. So it is prepared to act as a ZPM module.
You probably can install it as:
USER>zpm "load https://github.com/GendronAC/InterSystems-UnitTest-Mocking"
Hi @AndreClaude Gendron !
Raising again this topic - could you please share your project on Open Exchange? Thanks in advance!
It's not published on OEX, thus is not available on the public ZPM.
Calling @AndreClaude Gendron to publish it on Open Exchange.
In addition to what @Dmitry Maslennikov says here is the related information in docs.
Hi @Dheeraj Gupta !
Maybe this article and project by @henry could be helpful!
Also this project by @Dmitry Maslennikov could be of help.
Calling @Timothy Leavitt as Tim has a lot experience in Mocking. There is also a lib Forgery on OEX by @Rubens Silva that is related.
Hi Gautam!
It's not an answer for your question, but I encourage you to try manage tests via Package manager - in this case you don't need to create any directories and globals.
this will be:
USER>zpm "test your-package-name"
that will run all the tests. And you'll be able to introduce tests in a CI pipeline.
Thank you both @Dmitry Maslennikov @Gertjan Klein !
This is what I'm looking for!
Thank you, @Alex Woodhead ! This works for me!
Installed. But failing to form a connection string. Cannot it just use what I have for VSCode connected automatically?
It wants me to create a server in server manager which I never used before (no need).
Thanks both @John Murray @Dmitry Maslennikov
Thanks, @Alex Woodhead !
What about $objproperty and $objmethod?
The first one could be really helpful
Hi @Guillaume Rongier !
Is it possible to add Python based BO into the production with ObjectScript based components (Services, Operations)?
Thank you @Mark OReilly , @John Murray
Love it! Thanks a lot, @Alex Woodhead !
This is exactly what I need!
@Philipp Bonin - is it possible to switch the color scheme back to the one I used before? The one that comes with the extension is too bright for me) Thanks!
Thanks a lot, @Alex Woodhead !
@Philipp Bonin , maybe you could consider that in your wonderful ObjectScript to Embedded Python translator?
Hi @Alex Woodhead!
Having IPM client in place you can check the installed modules and its versions. The newly installed module will replace the old one.
I'm not sure I understand correctly what you are asking here. Anyway, one can setup their own IPM registry to supply its customers/clients with IPM modules. and this private IPM registry has the list of all the versions available and the stats of installations if this is set up. So any client that has access to this registry can install any desired version or just the latest if the version is omitted.
I'm not sure this functionality exists. It's better to have a newly published module version with the upgraded IRIS $zversion bytecode.
But if this functionality is in need please submit an issue.
Yes, indeed!
I had an issue with VSCode that didn't compile code. But VSCode window reload solved the problem and I saw the function in the list! Perfect!
Thank you, @Alex Woodhead !
Thanks Ed!
It is more that I convert ObjectScript to Python and it get stuck on Job command. Thought of something universal for such cases.
Thank you @James MacKeith ! This is interesting, never touched our WorkQueue Manager before.
Haha, this is good, @Alex Woodhead ! Thank you!
You also can manage it if you deploy your solution as an IPM package.
Here is an example of IPM manifest to deploy code without source:
<?xml version="1.0" encoding="UTF-8"?>
<Export generator="Cache" version="25">
<Document name="demo.ZPM">
<Module>
<Name>demo</Name>
<Version>1.0.0</Version>
<Description>DEMO.</Description>
<Keywords>demo</Keywords>
<SourcesRoot>src</SourcesRoot>
<Resource Name="Sample.Demo.PKG" Deploy="true"/>
</Module>
</Document>
</Export>
Here are the release notes on introducing the feature.
Regarding CSP - I agree with @Alex Woodhead, you better convert your CSP to CLS classes derived from %CSP with %OnPage() where you have all your HTML, and thus you can deploy without code.
And you can refer to this CSP classes similar as you refer to CSP pages.
Neat!
@Alex Woodhead , noticed you derived the class from Ens.Rule.FunctionSet
What benefits does it give?
I was hoping to see the compiled function in the available functions list here:

But it doesn't.
This was related to OwnObjectScriptExtension. It has a nice feature of converting ObjectScript to Python. It converts quite nice but gets stuck with such special variables.
Very interesting, @Philipp Bonin !
Translate to Python is really impressive feature!
Thanks, Robert!
Anyway I think every operation should expose these classes: request class and response class. They are like interfaces of a given service or operation.
And once I start building a transformation where it is known where the router gets the message(response) from and where it directs it the data transformation builder could show these message classes on the source and target parts of the transformation. This will safe a significant amount of developers' time.
If we think how this could be implemented, what about extending Operations with MessageClasses class, that will add two properties RequestClass and ResponseClass, that could be overridden with a proper class types by Operation developer?
This is crucial if we have a lot of 3rd party Operation and Services builders.
The links to InterSystems IRIS community Editions are updated.
The application should work either on IRIS Community Edition or IRIS for Health Community Edition. Both could be downloaded as host (Mac, Windows) versions from Evaluation site, or can be used in a form of containers pulled from InterSystems Container Registry or Community Containers: intersystemsdc/iris-community:latest or intersystemsdc/irishealth-community:latest .
Thanks for reporting!