Generating a report of which channels use each shared module

During a visit to a client hospital that is about to go live with a large eGate migration, one of the questions that came up during our discussions was how to see what channels are using a given shared module.

That functionality isn’t built into Iguana directly but because it’s easy to access the fossil source code repository (see Fossil repository layout) and the IguanaConfiguration.xml file it’s not a big job to write a script to generate such a report. So while I was down in Detroit that is exactly what I did.

The algorithm is quite straightforward:

1. Open up the repository into a temporary directory – the script assumes that the Iguana instance is running on Windows with a C:\temp\ directory.
2. Iterate through each of the GUID subdirectories and open their project.prg files.
3. Iterate through the shared dependencies in those project.prg files and build up a list of which shared modules use which channels.
4. Open the IguanaConfiguration.xml file, parse it and figure out which channels use which translator instances.

I put the report into a From HTTPS channel to make it easy to generate the report out as an HTML table so you get a header column which each shared module on the left. Then on the right you get a list of channels which use each module – with brackets indicating what component is using it – since there 5 possible translator components:

• LLP Listeners with custom ACK translator instance. (LLP)
• From HTTPS (H)
• From Translator (S)
• Filter (F)
• To Translator (D)

The formatting of the report is quite rough – but the report is useful so I thought I would put it up and see if other customers find it useful. For the source code go and look at the next tip in this series which is when I added search capability to the example script.

You can see the output of this script there too.

Hi, Works great in V5 but not V6. The xml config file has changed location to a sub directory (easy change) but it no longer contains <channel_config> which the script uses. I need to get a v6 equivalent to let me get a cross reference of shared modules. Any suggestions on what we can do now? Thanks, Alan

Hi Alan,

This is actually easier to do now than it was in the past, because Iguana needs to do this sort of mapping when it’s figuring out which projects are affected by a commit.

The snippet below uses an API that the GUI uses. Give it the name of a file, or a list of files, and it will tell you all the projects that use each of them:


function main()
local sharedfiles = {['shared/well_hello_there.lua']= {} }
local collation = net.http.get{url='http://localhost:6543/sc/collate',
auth={username='admin', password='password'},
parameters={file_paths=json.serialize{data=sharedfiles}}, live=true}
end


The list of files is a map, with the filenames as keys, and empty tables as values. The response is JSON, and looks like this:


{"files":
{"shared/well_hello_there.lua":
{"other_projects":
["1145539D867C4E69553AEF9771E98111",
"15D90DF1D1C7EE631080A090BD0C3643"
]
}
},
"projects":{
"1145539D867C4E69553AEF9771E98111":{
"contains_new_file":true,
"project_name":"Let's Make a Big App Better (From Translator)",
"shared_files":{"shared/well_hello_there.lua":true}},
"15D90DF1D1C7EE631080A090BD0C3643":{
"contains_new_file":true,
"project_name":"Let's Make a Big App (From Translator)",
"shared_files":{"shared/well_hello_there.lua":true
}
},
"tracked_files":null
}


The items in other_projects are translator GUIDs. There’s more detail about each of those projects lower in the response, including the project name, which is the channel name followed by the translator type in parentheses.

This URL (/sc/collate) is not yet documented as part of the channel API, because it will give unhelpful error messages if you don’t format the list of shared files correctly. Once those messages are friendlier, it’ll go on the formal list.

But in the meantime, it’s fine to use (Iguana uses it all the time!), and it should give you the info you need.

Hope this helps!

Ah okay – Just loading up my original code – I think it’s quite easy to tweak.

I loaded up the channel and took a stab at porting it over to work on top of Iguana 6.

The channel is up in Github now.

https://github.com/interfaceware/iguana-programming

You can see the change history to see what was required to make it work with Iguana 6. Less code is required than before because we have better APIs. The channel now works both on OS X and Windows now – the original was just windows.

Alan kindly provided some CSS tweaks that give a nicer styling to the report:

https://github.com/interfaceware/iguana-programming/commit/342f4928d3d43f69ae6c37b5c75b8657d8624f49

I dropped those in.

I’ve updated the code a little to simplify it and bring it up to our current knowledge of best practices and dropped in the basic authentication module so that it requires a login.

It also uses that to drive what sandbox to look at when it looks on disc to search through the modules.

BTW we’re always open to taking on contributions from our user community – if your organization does find that you come to depend on some internal utilities there are a lot of benefits of sharing that stuff with us. It means when new versions of Iguana come out it gives us the opportunity to port over those utilities so that burden doesn’t fall on your organization.

It also gives us good ideas on what people really find important and useful so we can keep folding that feedback into Iguana itself to keep the platform moving forward.

Good stuff here. And I agree about sharing code and ideas. Helps everyone.

I hope this forum gets some more traffic. Just getting started with Iguana, and love an active community!

Steve Ela
Macro Helix / McKesson
Software Developer / Integration Lead / Scrum Master