Forum Replies Created
-
AuthorReplies
-
Does the SVG object display? Is the error in the status bar a Javascript error?
If your using Apache you may need to add the following to your httpd.conf file and restart the service.
AddType image/svg+xml svg
AddType image/svg+xml svgz
Jonathan
Looks correct. Did you create the javascript source file (activateSVG.js)? For Apache, it must be in the /home/~user/public_html/javascript/ directory to work.
Here it is. There is some extra stuff in there that won’t apply to you but you should get the idea.
Cloverleaf Maintenance Server
if (parent.frames.length < 3) {
parent.location.href="http://naclvq03.unix.medcity.net/~hci/index.shtml"
}
Site: him_qa (none)
Location: Nashville RDC
Version: /hci/qdx5.4/integrator
Server Addr: 165.214.13.55
var obHTML = ”
This site is maintained by
Jonathan Hamilton
Copyright[code]
Cloverleaf Maintenance Server
if (parent.frames.length < 3) {
parent.location.href=”http://naclvq03.unix.medcity.net/~hci/index.shtml”
}
Site: him_qa (none)
Location: Nashville RDC
Version: /hci/qdx5.4/integrator
Server Addr: 165.214.13.55
var obHTML = ”
This site is maintained by
Jonathan Hamilton
CopyrightYes the plugin is required. I still use the Adobe one even though they have sunset it. It’s been the most stable.
We are trying to add support for Mozilla, Chrome, etc, but the way they deal with scripting is causing problems. The SVG’s will display just fine but the AJAX backbone doesn’t work the same so we lose our dynamic content, which is almost everything. I think Mozilla will be workable but the others I don’t think will be worth the effort to support.
Jonathan
In the UPoC Write TPS you should only use CONTINUE (success) or ERROR (failure).
When you use the CONTINUE disposition your messages out should increment and if you have a proc applied, the Send OK TPS will be executed.
When you use KILL, the message will be sent to the Send Fail TPS. If you do not have any code in Send Fail TPS or it returns a CONTINUE, the message will be re-queued (State 11) at the top of the queue for re-delivery. If you do not want to retry you would need to use ERROR inside the Send Fail proc.
You will need to use the Send OK/Fail procs to control the post delivery aspects of your UPoC protocol.
Note: in order for your Send Fail proc to run the Retries: setting on the Outbound tab has to be > 0, we typically use 3 or 10 depending on the interfaces needs. The Interval: settings is suppose to put a delay between retries but does NOT work, the messages will be resent as quickly as the engine can.Jonathan
You are overwritting each message, since you are writting them to the same message handle. Do a message copy of the original message handle (mh), then msgset the copied handle. In the end, you will likely KILL the original message handle.
If you are working with a large source message delete the data before you copy so the copy is faster.
# If large data, uncomment next line.
# msgset $mh {}
foreach … … {
set nmh [msgcopy $mh]
msgset $nmh $newmsg
lappend dispList “CONTINUE $nmh”
}
lappend dispList “KILL $mh”
You have to use Javascript to source the SVG object in IE thanks to their new IE security.
Attached is the javascript to source the object. But all it is is ‘document.write(obHTML);’ but it has to be in a sourced javascript file to work. Well, Clovertech won’t let me post the file so you would create the file activateSVG.js on your web server, then insert the code within the single quotes above.
Then in the HTML document I have the following:
var obHTML = ”
This works in IE 6 & 7, haven’t tried 8 yet.
Jonathan
Max,
Looks good.
Three easy ways to do it, which would be best depends on what you need to do with the data. Option #1 – Full control:
set split_data [split $data $seg_delim]
set index 0
set seg_index_list {}
foreach segs $split_data {
if [cequal $seg [crange $segs 0 2]] {
lappend seg_index_list $index
}
incr index
}
set in1Count [llength $seg_index_list]
Option #2 – Count plus the IN1 segment data:
set split_data [split $data $seg_delim]
set in1Segs [lmatch $splitData “IN1*”]
set in1Count [llength $in1Segs]
Option #3 – Just a count: (there may be a better regexp but this should work)
set in1Count [regexp -all {rIN1|} $data]
Jim,
Stephen Mattei and I are coming in on Sunday. We have UHC in production in you want to discuss/cry 🙂
Jonathan Hamilton
HCA Healthcare
John,
If you want to reverse the message you can try an OVER disposition but I don’t think it will work within the xlate thread. More likely, you’ll need to change the metadata DESTCONN setting to your inbound thread. Your method may vary depending on if you want to have the charge data translated or whether it be ready to send to the inbound thread coming out of your Tcl proc?
Jonathan Hamilton
Rey,
I think the best improvement would be the simplest, organization.
You might like these topics: https://usspvlclovertch2.infor.com/viewtopic.php?t=361&highlight= https://usspvlclovertch2.infor.com/viewtopic.php?t=587&highlight= There is tons of information available using MSI and netcfg api. From a UNIX server all of this information is very easy to access from within a Tcl cgi script. The negative is you are on your own to figure it out since some of the tools available are not (or no longer) supported. If you don’t know them yet learn the msi commands and review $HCIROOT/tcl/lib/cloverleaf/nci.tlib. If you are creative you can also interact directly with some of the daemons.
If you have specific questions or would like to see what’s possible you can email me.
Jonathan Hamilton
I tweaked the code some more, your car should be driving itself to Nashville now. 😯 With newer hardware you can push your threads per process count quite a bit higher. One of our smaller servers has 34 sites including our two largest sites, and is 7 years old running AIX 5.1 with quads and 4GB. Our two largest sites have 110 and 101 threads in 5 and 4 processes respectively broken out as follows. Site #1
Process #1 (LIVE) 51 Threads
Process #2 (ADT) 17 Threads (1 IB to 16 OB)
Process #3 (FTP) 5 Threads
Process #4 (TEST) 30 Threads
Process #5 (TEST2) 7 Threads (Specialized ODBC stuff)
Site #2
Process #1 (LIVE) 51 Threads
Process #2 (ADT) 12 Threads (1 IB to 11 OB)
Process #3 (FTP) 5 Threads
Process #4 (TEST) 33 Threads
We found that with very high volumes we faired better not dealing with inter-process communication so we group threads accordingly. The exception is with FTP related threads which use to have latency issues and in turn blocked the process. In our really large sites we have also segregated our ADT feeds to a seperate process to ensure they do not impact our clinical interfaces since some or our facilities do huge month end ADT batches which would delay clinical messages. This server averages in the 600K messages a day range and has a total of 1540 threads (not including cmd and xlate). We have 6 other prod servers with another <200 sites the busiest with over 1.1 million msgs a day. Enterprise wide we do over 4.3 million messages a day though <12K threads.
Obviously as Richard stated everything depends on what your interfaces do to the data, we use mostly raw routes with no data manipulation. If you have ODBC, FTP or very complex translations you can’t stack your threads this deep but depending on the speed of your processors you probably can get to 15-20 threads per processes. As you start increasing your size watch your message latencies to determine when you should start dividing your threads into more processes.
Jonathan Hamilton
-
AuthorReplies