July 14, 2009 at 5:55 pm #51054Phil AndrewsParticipant
What is considered “Best Practices” for site setup? We are considering rearranging threads to have sites seperated between adts, orders, and results, and arrange processes to seperate inbound threads from outbound. Does anyone else use this kind of logic? Our thinking is that when we are bouncing the interface engine we would follow the order of bouncing adt site first, then orders site, and last results. This also seems to make sense to us in the event of an unsuccessful fail over, and prioritizing which site to bring back up first. Thanks for any input.
July 14, 2009 at 6:31 pm #68609Max Drown (Infor)Moderator
Makes sense to me.
-- Max Drown (Infor)
July 14, 2009 at 7:33 pm #68610Gerri JacksonMember
Here at Mount Sinai, NY, we have split up our sites so that there are now 4 adt sites for the IP Cerner fed adt systems, 1 adt site for our IP IDXFlow adt systems, we have 2 lab sites, a radiology site, a charge site for charge processes, an “aps” site for miscellaneous interfaces. We also have a dedicated site for our Epic interfaces. As we move to migrate again to upgrade, we will most probably split out to a few more sites as they are getting crowded again!
July 14, 2009 at 8:52 pm #68611David BarrParticipantPhil Andrews wrote:
… arrange processes to seperate inbound threads from outbound.
I agree with everything you said except for that part. I think that it’s advisable to have threads which are connected by routes in the same process. This may not always be possible, but it should be a design goal.
July 16, 2009 at 1:11 am #68612Richard HartParticipant
We have one Cloverleaf site connecting to one application. Messages are translated in the appropriate Cloverleaf site. We use Unix links so that there is one copy of source files etc.
This is an example of one of our PAS sites [location RP] – the PAS connection is half duplex and we use ‘snd/rcv’ to indicate an extenal to Cloverleaf connection, in/out for a Cloverleaf site to Cloverleaf site connection.
Process Connection State Proto Status Count Started
top_prod_rp cap_prod_rp_adt_out up up 0 23/06/09 10:14:58
top_prod_rp ccm_prod_rp_adt_out up up 0 23/06/09 10:14:59
top_prod_rp cdc_prod_rp_adt_out up up 0 23/06/09 10:15:02
top_prod_rp cdr_prod_rp_adt_out up up 0 23/06/09 10:15:04
top_prod_rp cwb_prod_rp_adt_out up up 0 23/06/09 10:15:10
top_prod_rp eds_prod_rp_adt_out up up 0 23/06/09 10:15:11
top_prod_rp fdw_prod_rp_adt_out up up 0 23/06/09 10:15:14
top_prod_rp har_prod_rp_adt_out up up 0 23/06/09 10:15:15
top_prod_rp pma_prod_rp_adt_out up up 0 23/06/09 10:15:17
top_prod_rp ris_prod_rp_adt_out up up 0 23/06/09 10:15:22
top_prod_rp sol_prod_rp_adt_out up up 0 23/06/09 10:15:24
top_prod_rp top_prod_rp_adt_rcv up up 0 16/06/09 20:20:28
top_prod_rp top_prod_rp_adt_snd up up 0 16/06/09 20:20:29
top_prod_rp ult_prod_rp_adt_out up up 0 23/06/09 10:15:27
This is a consolidated [IH] clinical manager site
Process Connection State Proto Status Count Started
ccm_prod_ih anp_prod_ih_lab_in up up 0 14/07/09 10:00:38
ccm_prod_ih ccm_prod_ih_ack_rcv up up 0 25/06/09 04:10:04
ccm_prod_ih ccm_prod_ih_adt_snd up up 0 25/06/09 04:17:02
ccm_prod_ih ccm_prod_ih_lab_smt up up 0 24/06/09 07:00:44
ccm_prod_ih ccm_prod_ih_lab_snd up up 0 25/06/09 04:16:12
ccm_prod_ih ccm_prod_ih_ord_rcv up up 0 25/06/09 04:04:15
ccm_prod_ih ris_prod_ih_lab_in up up 0 14/07/09 10:00:45
ccm_prod_ih top_prod_ak_adt_in up up 0 14/07/09 10:00:49
ccm_prod_ih top_prod_bl_adt_in up up 0 14/07/09 10:00:55
ccm_prod_ih top_prod_fh_adt_in up up 0 14/07/09 10:00:59
ccm_prod_ih top_prod_gr_adt_in up up 0 14/07/09 10:01:09
ccm_prod_ih top_prod_ke_adt_in up up 0 14/07/09 10:01:17
ccm_prod_ih top_prod_km_adt_in up up 0 14/07/09 10:01:27
ccm_prod_ih top_prod_os_adt_in up up 0 14/07/09 10:01:32
ccm_prod_ih top_prod_pm_adt_in up up 0 14/07/09 10:01:40
ccm_prod_ih top_prod_qe_adt_in up up 0 14/07/09 10:01:46
ccm_prod_ih top_prod_rk_adt_in up up 0 14/07/09 10:01:51
ccm_prod_ih top_prod_rp_adt_in up up 0 14/07/09 10:01:59
ccm_prod_ih top_prod_sw_adt_in up up 0 14/07/09 10:02:01
ccm_prod_ih ult_prod_ih_lab_in up up 0 14/07/09 10:02:04
ccm_prod_ih ult_prod_ih_ord_out up up 0 24/06/09 07:00:46
July 16, 2009 at 1:28 pm #68613Russ RossParticipant
As we have now progessed to well over a thousand interfaces we had to redisgn and make more small sites to allow things to run in parallel more.
This promotes a better sharing of avaialbe resources with less contention and bottle necks and more granuality of control.
It also limits the impact that one interface can have on the rest when doing maintenance or prodcution changes.
Generally anything with route arrows connecting them are in the same process as much as possible.
We use jumps to send to other sites on the same box and hops to send to other processes in the same site and leaps to send to other cloverleaf servers.
These are the terms we use to refer to those types of interfaces.
Using one quick look at an ADT interface inbound to cloverleaf and following the path to just one outbound interface it goes thru the following sites.
1 – site to receive ADT and jump to a distribution site; only raw routes
2 – distribution site with only raw routes to jump to one of the outbound sites
3 – outbound site that has xlates and delivers to outbound systems (maximum of 8 outbound interfaces prefered)
For example in the screen shot below lets track one integration from start to finish.
starting with site prod_super_adt:
July 21, 2009 at 6:31 pm #68614James CobaneParticipant
I think the “best practice” is the one that makes the most sense for managing your organization.
- The forum ‘Cloverleaf’ is closed to new topics and replies.