Hi Andre-Claude,
Thank you for the contribution! We've begun to fold the use of this Mock framework into our daily activities.
I know this post is rather old, but I do have a question. Some of the classes in the repository use classes that are not present in the repo any where (Tests.Fw.Mock.CIsEqualObjectParamValidator for example). If you are willing, would you be able to commit those to the GitLab site?
Again, thank you for sharing this with the rest of us.
As a follow up -- we might do this as a post-processing exercise and just deal with the initial %Save -- but I am curious if the split can happen earlier.
Aaaaaaand that's the memo I missed. My 2021.1 instance was below rev level. Thank you so much for the help!
Wow, good eye on that. Yes, that pattern holds true:
.png)
One of the best features I've run across in these types of tools is the ability to remember the anonymizations that were applied to a message. For example, you would define the MRN and Encounter Number fields as key fields for an HL7 message type and whatever transformations were applied to the first message with those keys will be applied to any of them that follow. It is certainly a non-trivial feature to implement, but it gives you the ability to keep a patient encounter intact as the visit goes from admit to discharge. This scares out a lot of problems before go-live.
Regardless, nice work and thank you for your efforts.
Right, I understand the predicate aspect of FindDocuments(), but I understood that any value used in a predicate must first be created as a property with CreateProperty(). The doc for that method is sparse, and I have not quite grok'd how a dynArry would play into the expression. Creating a property for "FullName" is pretty self-explanatory, especially since it is at the root of the hierarchy. I've also seen an example in the forums where a property was created using a specific index in an array -- which would not be terribly useful for an unordered collection. Assuming that the person object in the example is the document in the DocDB and the PhoneNumber array above has no particular order, what would be the expression used in CreateProperty() for "type" and/or "number??
I think once I see how that particular aspect is supposed to work, the rest of it is easy.
Thank you all for taking the time to offer help.
Thank you, Luis. As someone just getting started with DocDB, I appreciate you sharing your experience and helping save me (and others) some frustration.
Yep.
%SYS>Do $system.Python.Shell()
Python 3.9.5 (default, Jun 2 2023, 14:12:21) [MSC v.1927 64 bit (AMD64)] on win32
Type quit() or Ctrl-D to exit this shell.
>>>
As I try to go a little deeper into importlib, it seems that find_spec should be passed a path that "produces strings when iterated" and there is something about the deployment environment that is causing path to be passed as a string in this case. Only happens when using python-augmented (method) COS classes, as far as I can tell.
Okay, here's the latest.
I had started to outfit some of our repos with boilerplate IPM modules to take advantage of the requirements.txt processing. Modeling some of the things mu team and I had seen elsewhere, we put a FileCopy in the module file to copy the contents of the repo's python directory to a subdirectory of lib/python that matched the root package name.
A high-speed team member picked through the custom loader to suss out the behavior and found that once it encountered the subdirectory matching the root package name, the resolution of the modules that are stored in globals never happened.
So, removing the directory restored the default loading behavior and I will caulk it up to my poor understanding of how repo-based modules are supposed to be deployed.
Assuming that we will eventually have file-based .py modules to deploy, what is the best way to keep FooOperation.py from one namespace out of the way of FooOperation.py in another?
UPDATE: Adhering to PEP8 conventions on naming packages using lower-case letters and underscores nicely sidesteps this issue. So, for namespace with a root package of "MyFirstPackage" would have a lib/python/myfirstpackage folder with any .py files that need to accompany the namespace in it.
The loader failing because the package matched the root namespace is probably still a bug of some sort, but now that I know a little better about naming conventions I can see why this might not have been tested.
Hope this saves some of you norms (like me) some time if you run across it.
Believe it or not, yes. Ultimately, edi-dev will sell a SEF for $60 US if you can show proof of license from X12 (I had a conversation with them after my original post). The internal license we are going to need from X12 will get us access to the XSD for the messages, which should me usable as a means to get the schema into IRIS (so I'm told).
Thank you @Evgeny Shvarov! The bots all give similar answers to DC AI Bot. Your answer is priceless.
Thanks for everything you give to the community.
- Jonathan