Best practices for Cloverleaf interface support tools

Clovertech Forums Cloverleaf Best practices for Cloverleaf interface support tools

  • Creator
    Topic
  • #122296
    Arkadiy.K
    Participant

      Hi everyone,

      Looking for advice and patterns from teams that have gone deeper than ad-hoc scripts for Cloverleaf interface visibility, documentation, and impact analysis.

      Current state

      We already have custom command-line tools that parse netconfigs, xlates, and related artifacts to answer common questions. They work, but they’re:

        [*]clunky to use
        [*]not very discoverable outside the core team
        [*]tightly coupled to local CLI access

      As we look toward a more cloud-friendly future, we’d like to rely less on command-line tooling and move toward something that is:

        [*]queryable
        [*]searchable
        [*]accessible to support teams (not just Cloverleaf engineers)

      What we’re trying to build

      At minimum, a support database (or structured dataset) — possibly starting as a spreadsheet — that represents end-to-end interfaces, not just individual files.

      Key use cases

      From netconfigs

        [*]Show all interfaces for a given external system (e.g., Epic)

        [*]inbound / outbound connections
        [*]associated xlates
        [*]tables and ports

        [*]Search by:

          [*]IP address
          [*]port number

        [*]Quickly answer:

          [*]“What interfaces are tied to this endpoint?”
          [*]“What breaks if this port/IP changes?”

        [/list]

        From xlates (where things get really interesting)

        We’d love to support impact analysis, for example:

        Epic announces: “We are not going to start sending PID-20”

        We want to query:

          [*]Which ADT interfaces reference PID-20?
          [*]Which specific xlate files are impacted?
          [*]Which downstream systems would see impact?

        In other words, the ability to answer:

          [*]“If Epic adds/removes a field or value, what breaks?”
          [*]“Which xlates depend on this segment/field/component?”

        Even partial visibility here would be a huge win.

        Nice-to-haves / future state

          [*]Generate interface diagrams from structured data
          [*]Potentially use Copilot / AI to:

          [*]visualize flows
          [*]explain xlate logic
          [*]surface dependencies automatically

          [*]Something maintainable and auditable (not tribal knowledge)
          [/list]

          Questions for the group

            [*]How are others solving this today?
            [*]Spreadsheet, database, CMDB, custom UI, or something else?
            [*]Has anyone:

            [*]parsed xlates structurally (segments/fields used)?
            [*]built dependency graphs from Cloverleaf artifacts?

            [*]Any lessons learned moving away from CLI-centric tooling?
            [*]Tools or approaches you’d strongly recommend (or avoid)?
            [/list]

            Happy to hear both success stories and cautionary tales — we’re trying to evolve without over-engineering.

            Thanks in advance.

            • This topic was modified 2 days, 14 hours ago by Arkadiy.K.
            • This topic was modified 2 days, 14 hours ago by Arkadiy.K.
          Viewing 1 reply thread
          • Author
            Replies
            • #122299
              Jim Vilbrandt
              Participant

                Hi Akadiy,

                we are creating nightly exports of all NetConfigs into two CSV. One for the protocol details and one for the route details. We have been thinking about how we can present this information to our general support users in a more useful and friendly manner. So we are looking forward to how other respond.

                Regards, Jim

              • #122303
                Jason Russell
                Participant

                  Without writing your own external tools, I don’t think there’s anything that will do what you want natively.

                  There are a few limited pre-built tools:

                  1. CLI – Unlimited access, only limited by what you want to do, programming skills, time, etc. However, if I’m not mistaken you do NOT have access to the CLI on Infor’s cloud solutions. Other solutions you have access (AWS, Azure, etc) just like you would locally.
                  2. GUI – Requires engineer access, no real reporting. Full access.
                    1. They have a ‘site documentation’ tool, but all it seems to do is a printout of the NetConfig and various files being used (TCL, PDL, Xlates, Tables, etc). Not very informative imo.
                  3. Global Monitor – Has a listing of all interfaces in one space, can access all connection data (though not easily). Gives basic access to start/stop threads and processes. Essentially a monitoring for connectivity.
                  4. Cloverleaf Wizard – Web-based access to some very limited development tools. Can modify Global Variables, ports, thread names. Cannot (currently) modify xlates, scripts, etc. We haven’t used this at all so I’m not sure how deep functionality goes. This is more a tool for non-engineer analysts to update tables and other basic functions.

                  Infor seems to be expanding their Wizard tool. We’re on 2022.03, and I haven’t read the release notes for 2025 fully yet (we’re not quite ready to upgrade yet). I wouldn’t be able to speak on versions prior to 2022.03.

                  So point by point, I will try to point you to the best tool:

                  <strong class=”d4pbbc-bold”>From netconfigs

                  Show all interfaces for a given external system (e.g.,

                  <em class=”d4pbbc-italic”>Epic

                  inbound / outbound connections / associated xlates / tables and ports

                  • This can be done with either the GM or Wizard. Wizard is a little more ‘pretty’. GM is a teensy bit easier to switch between sites (by like 2 clicks).

                  Search by: IP address / port number

                  • I haven’t found any way to search via either the wizard, GUI, or GM. The only way I’ve been able to ‘search’ for a port is via the command line. There are ways to view (GM+Wizard) and edit (Wizard), but not search/list that I’ve found.

                  Quickly answer:

                  “What interfaces are tied to this endpoint?”

                  • Both GM and Wizard have route views, much like the Network Monitor and NetConfig.

                  “What breaks if this port/IP changes?”

                  • I don’t think this is possible to answer via a command. I mean that’s a “it doesn’t work the same way”. Not sure that is answerable by any method other than just doing it and testing.

                   

                  <strong class=”d4pbbc-bold”>From xlates (where things get really interesting)

                  I don’t think any of this is going to be available with the current tools, and I’m not sure if there’s any plans for implementation. This would require 3rd party scripts/programs/etc to do any of the items listed under this. I get the need for this, but not for non-engineers. Doing this in-place (ie no exports) is possible from the command line.

                  <strong class=”d4pbbc-bold”>Nice-to-haves / future state

                  Generate interface diagrams from structured data

                  • See GM and CL Wizard above. I’m not sure if there’s much more  you want than what they already offer in this regard. It looks very similar to the NetConfig/Network monitor screens in the GUI.

                  Potentially use <strong class=”d4pbbc-bold”>Copilot / AI  to: visualize flows / explain xlate logic

                  • This requires documentation. You can potentially use AI to read the code, but it would have to understand how to read the Cloverleaf NetConfig and Xlates (which are essentially TCL lists). Honestly, we don’t document as well as we should either, but the difficulty of this comes from attempting to do this globally. There is still a lot of ‘legacy’ code in many instances which would complicate this. Then you have the fact that people code differently, and there’s different ways to execute different ways to drop messages in Cloverleaf. AI may get you a good head start, but I have a feeling that regardless of the tool it’s going to require intervention to make sense. This also only applies to workflows and data flows in one piece. This wouldn’t take into consideration an order and result paired feed, as Cloverleaf nor AI would really have a way to link those without naming schemes or other ways to ‘automatically’ link these. AI tools can help you write these, but I don’t think there’s going to be a good way to do this automatically.

                  surface dependencies automatically

                  • This could be done with scripts, but again you, Ai, or whomever else is going to have to write in how to do this and be able to link the pieces together to do this properly.

                  Something maintainable and auditable (not tribal knowledge)

                  • My thought on this here is “document, document, document”. Use AI tools to help you, but I don’t think any automatic tool is going to replace you documenting your work and what it does.

                  <strong class=”d4pbbc-bold”>Questions for the group

                  How are others solving this today?

                  • Scripts! We just got into Cloverleaf fully (finished our migration), now the next step is to start working on scripts to do this. We are a CLI and GUI shop and have no intent to change, so doing a lot of this from “outside” the server doesn’t suit us. We use the Global Monitor, and I’ve been looking at the Wizard for non-interface people to maintain a few things. Documenting is key. We may have to change how we work, but right now using a mix of tools is how we do it.

                  parsed xlates structurally (segments/fields used)?

                  • Not yet, not sure if we’ll do that, or just continue to expand documentation. I did look into parsing HL7 messages themselves to see what is being used, but that was a pet project of mine that kept getting sidetracked.

                   

                  With all of that said, it seems you’re looking for an ‘easy’ button to quickly understand a workflow and intricacies of data flow within Cloverleaf. I don’t think that’s really possible. This especially true with attempting to get this information to “outside the team”. I, personally, would not want people trying to make sense of any code. There should be documentation to help explain the function of an interface. Using tools to attempt to read code, directions, filters, translates, etc without an ‘interpreter’ of sorts is a bad idea, in my opinion. I feel like interface, especially are on the decline (definitely not gone any time soon), and with Epic pushing their App Orchard and FHIR really hard, as well as other vendors getting on board with that, I would expect many of the HL7 interfaces to be on their way out, and eventually be a legacy thing.

                  With all of that said, even Epic does not have a ‘magic button’ to show all data flows. It takes analysts and tools and interpreting. But the larger and more complex  your system, the harder it is to do that without attempting to homogenize data so it’s all the same for everybody (which it will never be). We’re running into that issue with a few vendors who keep claiming “we work with Epic!” and then everything they want to do won’t easily integrate with our Epic implementation.

                  It’s also REALLY hard for a ‘middleman’ software (which is what Cloverleaf is) to see data flow from a global level.  You can force linking via different methods (again, naming schemes primarily), but there’s no easy way to say how the data flows, ESPECIALLY if it hits another piece of software then comes back in. Almost any thing to help ‘explain’ what is going on would be through notes and documentation.

              Viewing 1 reply thread
              • You must be logged in to reply to this topic.