go to post Mike.W · Jul 27, 2018 Hi, I also help support an NHS trust using Ensemble, and it also has ever-growing PDF files in messages. We have our incoming PDFs as external file streams and it helps, though you have to bear in mind that the files are not going to be part of the cache backup for Disaster Recovery, etc. (Not sure about mirroring. I'd assume they don't get mirrored either as the contents are not in the journal.)As yet, we don't have as big a problem as you - less messages and we only keep 92 days - but that is just as well as the PDF files are converted to base64 encoded in HL7 v2 messages, so they then do take up space in the database, and the journal, and the backup, which has resulted in the need to expand the disk space recently. I can recommend keeping Ensemble on a virtual server with disk expansion on demand.I tend to think the problem is not going to go away whatever you do. I assume, like us, the PDFs come from 3rd party applications and they are always going to be producing ever more and prettier documents as time goes by. So I recommend looking at more disk. :-) / Mike
go to post Mike.W · Jun 15, 2018 Hi,I won't claim this is an answer, because it's not quite the same and people may object to the structure, but here is one solution that is used quite a lot in code I look after. Basically, a subroutine is called and then tests are done and a Quit is used to drop out when a match is found. Often used for validation, something like this that returns a result in the zER variable:V1 ; Validate ORGC S ORG=zORG D WC2^hZUTV I zER'="" Q I IPACC<9,'$D(^hIW(WAID)) S zER="No details set up for ward" Q D WARDON^hILO1 I LOCK S zER="Ward in use" QVQ2 QApologies for the old-fashioned code! However, you can see each test can be quite complex and using lots of variables, but it is easy to understand as long as you expect the structure to work that way.This is very similar to the "clean code" solution of making the whole thing into a function that returns a value: ClassMethod Main(val1 As %String, val2 As %String) { write ..MyOutput(val1,val2) } ClassMethod MyOutput(val1 As %String, val2 As %String) As %String { if val1 = 1 return "case 1" if val1 = 2, val2="*" return "case 2" return "default match" } Of course there are probably as many answers as there are Cache programmers! :-)
go to post Mike.W · Apr 20, 2018 Yes, we have something like that, except we use the letter "q" as the prefix, and we follow it by the programmer's initials so that it becomes a "personal" set that is left alone in all namespaces, dev-test and live. We also extend this to rule to globals and things inside the application like functions, screens, tasks, etc. The in-house configuration management system we use ignores them so they are left untouched. It's a useful convention.(We might have used "z" like you, but it was already taken for "utility/library" stuff.)
go to post Mike.W · Apr 19, 2018 Neither - I think it best to just remove all the code and leave a stub with just a comment (usually with the change request id and reason).That ensures the unused code is removed from all downstream libraries, so does not pop up in searches and testing, and yet keeps a record of its previous existence. I've always been against leaving unused code in source files, even if it's "commented out".
go to post Mike.W · Feb 21, 2018 Anyone know why we ended up with this strange behaviour? Why doesn't COS store 2 and "2" in the same way in lists? The rest of the programming environment is based around them being the same - (2="2") - as everything is a string until used otherwise. It may use "an optimized binary representation", but surely that's not really an excuse. Just curious.
go to post Mike.W · Feb 21, 2018 An alternative solution that works for us is to use the "Schedule" setting to run it for 30m (to allow some leeway as the job takes a while), and then set the "Call Interval" setting to something very large like "999999". This is for an Inbound SQL adaptor. (If something goes wrong with this overnight run then we manually remove the "Schedule" setting and restart the Service. Once complete, we put back the setting ready for the next night.)
go to post Mike.W · Jan 12, 2018 Hi.I'm not sure what your "persistent objects" contain, but if the repeating data is in the form of strings or streams then perhaps you could put them into a XPATH document object ( %XML.XPATH.Document) and use the evaluator in that? I support a system that has a message with a transient property to hold the document created, so it's only done once (per processing), and a method that builds that property if needed and then calls the EvaluateExpression method in that property for an expression supplied as a parameter. This is used in transformations to extract data to post into HL7 v2 messages, so the same calls should work in rules as well.Of course the XPATH expressions may be no easier to define than your exporting and importing methods. I certainly struggled with them and in the end had to build lots of special inputs that added the huge long list of nested items that usually went at the front of each expression, resulting in calls like source.Pull("Baby","ep2:id/@extension") where "Baby" added a prefix of over 160 characters to find the baby section of the Mother's full document before tunneling down to the hospital number. If you already have a sub-section of the full document then you may not need as much.Mike
go to post Mike.W · Jan 4, 2018 Hi. We had a site upgrade from 2012.2.5 to 2017.1.0 last year, and it included a mirror. We had very few code changes needed - just an issue with it failing to save objects inside a Business Process where we had used some "unusual" structures. The upgrade itself went smoothly. The only issue was afterwards when the next backup was a "full" one instead of the scheduled "partial", using more space than expected. Our Production was much smaller than yours, with only about 120 items, and it is hard to say how much effort went into pre-release testing as it was "fitted in" around other work by a team of people. Maybe a couple of man months?To be honest, it all depends on how much custom or unusual code you have, and how much testing the customer wants. We upgraded a development namespace and re-ran test messages through all the important paths and compared the result before and after upgrade. Plus some connection testing to cover all the "types" we used: ftp, web service, HL7, etc. In our case the testers included people from the user side, so they could decide when they were happy with it.InterSystems were very helpful. We raised a call a few months before and they gave advice on testing and desk checked our detailed plan of the upgrade itself, including how to do the mirror.Good luck.
go to post Mike.W · Dec 20, 2017 Hi - we may be overcomplicating the solution here. Rather than comparing the age for every record, all you need is to work out a single cut off date to compare against the DOB. This was given in Jill's answer above, but another variation that might be clearer is:WHERE DOB < todate((tochar(current_date,'YYYY')-12)||'0101','yyyymmdd')Also, the usefulness of an index will depend on the ratio of under 13 to over 13 records. If the vast majority are to be included, then use of an index may slow access down as the system flips back and forth over the main global, whereas a straight run without an index could be quicker (hopefully the compiler would work this out for you).Regards,
go to post Mike.W · Dec 8, 2017 I won't embarrass myself by listing the MUMPS code from 1991 that does this on our application, but I will comment that you need to work out how many birthdays have gone by so it must compare month and day values once the basic year subtraction has been done. It gets quite complicated. (Might also like to look at whether you need more than just a "years old", and also need months or days for very low values.)Mike
go to post Mike.W · Dec 8, 2017 I have used the %XML.Writer class to create a document, but only for a fairly simple one that was destined for a SOAP outbound call. The SDA is tricky, so I would imagine using HealthShare (Ensemble) would be much easier. (I have used Ensemble classes like EnsLib.EDI.XML.Document that can be added to a message, etc. and used as the target for transformations once you have an appropriate document definition loaded in. Reduces the coding required, though not entirely as repeating groups are an issue.)Mike
go to post Mike.W · Dec 8, 2017 I'm just thinking that maybe we need more information as to why this is needed before recommending anything. If the network connection is good enough for mirroring, then why not just map the classes to a central repository? Perhaps all that is needed are security settings to prevent updates from the "slave" systems. Perhaps there is no network connection, in which case mirroring or shadowing is not possible, and what is needed is a good way to automate export/import to OS files.Mike
go to post Mike.W · Nov 23, 2017 I may have misunderstood your requirement, but you may not need a Business Rule at all. To pull data from the request into the context I've actually used Transforms.To get this to work, I created a new class that Extends (%SerialObject, %XML.Adaptor), and defined in it the properties that I need to store. I could then define a Transformation from the incoming message type to this new one, pulling everything I needed. In the BPL I then added a property called "TempStore" of that type to the Context object in my BLP. To pull the data I added a Transform Activity with a Source of "request" and a Target of "context.TempStore" using the Transform.Later Activity boxes could then use the fields with references like "context.TempStore.priorMRN" to do tests, etc. I've also used the same trick to update outgoing messages with data from the context (using Create = existing in the Transform).I hope this is useful.Regards,Mike
go to post Mike.W · Nov 17, 2017 if you open the class in Studio, and view the "Inspector" pane, then pick "Property" from the first drop down and your property in the other (or double click it), then it shows a very long list of possible things you can add. It may even show all of them, I don't know. You can then click on the values to enter them, sometimes getting drop down lists of possible values.I've often used the inspector as a way of finding out what might be available, and then searching any keywords in the Caché documentation to confirm how to use it.Regards,Mike
go to post Mike.W · Nov 1, 2017 Amir's answer with option 2 is what we did. The XML we sent had to be converted to allow it to be sent, so our code looked a bit like this:Method ImportEpisode(pRequest As EnsLib.EDI.XML.Document, Output pResponse As Ens.Response) As %Status{ ; Use format 8 bit regardless of cache default (else Base64Encode gives ILLEGAL VALUE error) Set sendingXML = pRequest.OutputToString("C(utf-8)",.tSC) If $$$ISERR(tSC) Quit tSC $$$TRACE("Sending: "_sendingXML) Set sending = $system.Encryption.Base64Encode(sendingXML) Set tSC = ..Adapter.InvokeMethod("ImportEpisode",.result,sending,{plus some other id parameters}) If $$$ISERR(tSC) Quit tSC Set resultXML = $system.Encryption.Base64Decode(result)...etc.I hope this is useful to you.Mike
go to post Mike.W · Aug 8, 2017 Many guides to "good programming" (in any language) would advise that the return from a function/method should be used for "real" data only, and any "exception" situations should be flagged as an error. While I'm not convinced this is always the best way, I can see the advantages. Code with repeated tests of returned status values can be messy and hard to read, and if the only thing it can do when the status is a fail is to quit out again with a status of "failed", then there is not a lot to be gained.Mike
go to post Mike.W · Jul 26, 2017 I had a similar situation and ended up with an Ensemble Service reading in the meta data file (like your xml), and composing an Ensemble message with that information, including a file reference for the data file (your pdf). This meant that the meta data file could be automatically archived by Ensemble, but now I had to archive the data file instead, using calls to the OS like you have done for your xml file above.In my case this did make some sense, as I wanted to convert the data file using an OS call to an "exe", and at least the messages in Ensemble had all the meta information, file name, etc. But I also think it was a bit clumsy so would be interested in any better ideas.Regards,Mike
go to post Mike.W · May 2, 2017 The timeouts for the web front end can be frustrating. Where we had searches that we wanted to do regularly we have ended up creating a Business Service class that does embedded SQL queries on the Ens.MessageHeader table, and puts the results into a simple text message that then gets sent as an attachment to an email. This gives us our daily stats in a CSV format to copy and paste into a spreadsheet. Yes, we could have built an XML spreadsheet file directly, but that is tricky, and not much of an advantage as we want to build on it each day without the query working through many day's of data.We also had a go creating something using Ens.BusinessMetric for a "recent activity" graph, but the end result was a bit limited in how it could be displayed and analysed (using DeepSee) as we only had the Ensemble license.Mike
go to post Mike.W · Mar 10, 2017 Hi,We have an Ensemble Service class that extends " EnsLib.SOAP.Service" and provides a web method with a parameter that is a class that includes a property of " %Stream.FileBinary", plus all the meta data in other properties. This allows the source application, written in .net, to send us documents fairly easily, as all the translation back and forth into xml, etc. is done for you (I assume it is also easy to do at the .net end). There is not a lot of code needed to define the class and web service, then it just needs to build a message object with that same input class as a property, and send that onwards as usual.(Unfortunately, we then have to convert the file into base 64 encoded chunks and insert into segments in one of those MDM^T02 messages like you do. But that's another story.)Mike
go to post Mike.W · Oct 4, 2016 A lot of the code we have to deal with is like the "One Line" method, but then some of it was written back in the days when there was very little space in the partition for the program, and the source code was interpreted directly, so it had to be kept small. What is different is that while the code to handle the traverse is all kept on one line, which I think makes the scanning method clear, other code for pulling and writing stuff is usually on lower "dotted" lines, like this: S Sub1="" F S Sub1=$O(^Trans(Sub1)) Q:Sub1="" D .W !,"Sub1: ",Sub1 .S Sub2="" F S Sub2=$O(^Trans(Sub1,Sub2)) Q:Sub2="" D .. ; etc And yes, it uses the short version of commands (as you did for the Quit, I notice). I'm not saying this is the best style to use, obviously, as things have moved on, but we do still tend to use it when amending the old code. I think it is useful to be aware of all these variations, as you may come across old code using them. Also, sometimes the array structure can be better or faster than objects and SQL, whether in a global arrays, or in temporary local arrays. Its a very neat and flexible storage system. Mike