@david-barr
Forum Replies Created
-
AuthorReplies
-
If you’re just decoding the base64 data and not passing it anywhere you may not need to remove the linefeeds. The decode will ignore them, and they shouldn’t affect your field lookups since they are using \r and | as delimiters. If you do want to remove the linefeeds, I think you could do something like this:
<pre>set msg [msgget $mh]
set msg [string map { \n “” } $msg]
set ctr_val [msgmetaget $mh “USERDATA”]
set segmentList [split $msg \r]</pre>Do you have an example message? Is the line feed part of the encoded characters, or is it after? Is Cloverleaf decoding the base64 or is it being passed to another system? This should be easy to do in TCL.
In my experience there are very few tutorials for any Cloverleaf usage outside of official Infor training. There is online documentation for the Python API, and at least one example that is installed with the Cloverleaf. I don’t know how much the official training classes would cover Python. The Python API seems very similar to the Java API, so it’s possible that you could infer additional information from the Java documentation and examples.
I think you just put the site folders under version control. That’s pretty much what we did. What questions do you have?
If you’re using SVN, you would set up an SVN server then run “svn add” in each of your site folders.
We’re still trying to make option 1 work (from your post above), and it’s going well.
I ran a test yesterday with 8 outbound threads on Cloverleaf. I had about 85,000 messages. I created the messages according to the Epic specs, but I only included the pathname to the document rather than the contents in the message. When I was building the file, I also put a thread ID (CONV1-CONV8) in MSH-5. I resent all the messages to the inbound thread at once. I had a filter on each route based on MSH-5 so that each outbound thread would process a separate set of messages. The outbound thread would add the base64 encoded document contents to the message in a prewrite proc to delay bloating the messages in Cloverleaf for as long as possible. Also, every outbound thread was in a separate process so that work of reading the document into the message wouldn’t block activity on other threads.
On the Epic side, I set up 8 inbound interfaces to process the messages, and I used the system defaults (IC_IN_TABLE) to route the messages to separate interfaces based on MSH-5. Also, I had all my Cloverleaf threads sending to the same IP/port and there was a load balancer to spread out the work of saving to the web blob server.
For this test we were able to process about 1000-3000 messages per minute which may be fast enough for our needs. We can add more threads, Interconnect servers and Bridges interfaces if we need better performance.
Our Epic TS didn’t like option 2 because there’s more complication of associating the files on the blob server to the HL7 messages.
What do you want to use Azure for? Just hosting your Git repos?
Git workflow doesn’t really do that much for our Cloverleaf development. We can’t have multiple devs cloning separate copies of a site and running them independently due to licensing issues for servers. We generally do all your development in test versions of our production site on a test server. If you have multiple devs, they are generally logged into the hci account and working with the same set of files.
We’re stilling using SVN instead of GIT. My opinion is that most of GIT’s advantages don’t apply due to the Cloverleaf restrictions, so I haven’t seen the need to move. We have separate branches of our sites for test and prod. We check our changes into the test server and merge the changes from the test branch to the prod branch on the prod server. Our SVN repo is on a totally separate server running Trac (trac.edgewall.org). I think the same type of configuration should work for GIT, and locally hosted GIT vs. cloud hosted should be similar.
I suppose that having pull requests for the prod branch could help with change management. In that case you could keep a copy of your prod sites (not running) on your test server, merge your changes from test, push the changes to Azure, make a pull request. Someone approves the request, then pull the changes down to your prod server.
May 9, 2025 at 11:12 am in reply to: NoClassDefFoundError in WebServer process after adding database actions #122026It does sound like a CLASSPATH problem. I’m not very familiar with how environment variables are set in Cloverleaf under Windows. I’m more familiar with Linux. If you can get tech support from Infor that would probably help.
I would see if starting the process from the command line (hcienginerun command) vs. starting through the host server vs. having the processes auto-start with the service makes a difference in how it behaves.
Someone probably wrote a script outside of Cloverleaf that is doing this:
hcicmd -p processname -c “bogus cmd to see if process is responding”
This is probably in a script that is checking if your processes are stuck. I’ve never heard of this before, so it’s probably written by someone specifically for your organization.
Do you know about how the forward queue works? If that’s going to be a problem I could probably make a loopback interface to another thread, await replies, and have the second interface add the PDF and forward the reply from Epic. But if the forward queue can’t get big I don’t want to bother with that.
I would try to find out if they’re using HTTPS or HL7 MLLP+TLS. HTTPS is more common.
They should send you a lot more information than you’ve provided here: protocol, server address, port, authentication type, TLS version, etc.
you could have the non-ADT get to the DMS first
To prevent this you could have your script that moves the files from the hold directory run from the Send OK TPS of the ADT thread.
I’ve done stuff like that using the “java/ws-rawclient” protocol. It may also be possible with the “http-client” protocol. But if you want examples from me, they would be using ws-rawclient which requires a web services license.
Cloverleaf can’t work with multiple developers like normal software projects. If two developers make separate clones of the repo, they can’t both be running at the same time since Cloverleaf relies on having a single HCISITEDIR and specific file/folder structure under that.
What we’ve done is have all of our users open SSH sessions to their own accounts, sudo over to the hci account, and run version control commands as hci. We’re still using SVN since we haven’t seen much need to switch to GIT given the Cloverleaf restrictions.
You could probably put all of your files from HCIROOT into a repo, use .gitignore files to exclude folders that aren’t maintained locally at your site, and make separate branches for test and production. Commit files to your test branch, merge them into the production branch and pull them from your prod server.
Like I said, we’re still on SVN and we do something similar, so hopefully someone who manages their environment with GIT can respond.
I think you need to include more of the log file. The Traceback and the lines below it are usually helpful for troubleshooting.
For connections from Cloverleaf to Epic we’re using ClientAuth mode, TLS 1.2.
This is what the TLS settings look like on the Epic side:
Server, TLS 1.2 – Client authentication required Key type: RSA Cipher List/Suites: AES/STRONG Cert validity: 2023/10/16-2025/10/15 CN: epicprd.Valleymed.net Issued by: UW-Valley Medical Center Issuing CA2 CA validity: CN: Issued by:
For Epic to Cloverleaf we’re using Server mode, same version.
-
AuthorReplies
