Versions Compared

Old Version 4

changes.mady.by.user Eliot Muir

Saved on

compared with

New Version Current

changes.mady.by.user Aryn Wiebe

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This exercise is intended to help you understand the difference in design philosophy of Iguana X IguanaX with Iguana 6.

HTTP https//bitbucket.org/interfaceware/export named DemoImport
Expand
titleSTEP 1: In Iguana 6v6.1.4 5 go to Settings > Add/Configure Repositories
Expand
titleand create a DemoImport repository

Create a new

repository

:

Image Removed

  • Make the name DemoImport

  • Select Protocol HTTPS

  • Copy paste this inthe repository url:

    Code Block
    https://bitbucket.org/interfaceware/export
Image Added
Expand
titleSTEP 2: Import all the channels from the new repository

title
Expand
titleCompare STEP 3: In Iguana 6 and IguanaX, compare the LLP Listener configuration in both products - what do you notice is different?

In IguanaX we have:

Image Removedsimple.pngImage Added

Versus in Iguana 6:

Expand

What is different and why?

Iguana 6 looks like the complex dashboard of a 747 plane - there are lots of different options which most customers leave on the defaults.

With IguanaX a design goal was to make the operation of interfaces simpler by soft coding the components in Lua but giving each component a lot less configuration fields so that more attention can be given to what actually matters.

When you need to customize components we have made that simple.

Expand
titleFind STEP 4: In the IguanaX Importer component, find the code where we map from the LLP Listener in the Converter component in Iguana X

Hint - look in the source code of the converterimporter.

Look at the CHAN/CHANllpSource.lua file. This defines the mapping of configuration information from Iguana 6 to IguanaX.

Also look at the calls to CHANcreateStandardComp in CHAN/CHANmain.lua:

Code Block
CHANcreateStandardComp(Dir, C, "from_llp_listener", "#source #llp",
                 "git@bitbucket.org:interfaceware/hl7_server.git")

These calls define the mapping of Iguana 6 components to IguanaX components.

...

title
Expand
titleWhat are we aiming for?

We’re trying to hit the sweet spot of understanding the simple common set of usage that most people need. That way we can make simple components which are intuitive to understand in terms of their configuration and their implementation.

Unusual requirements for a few interfaces shouldn’t come at the cost of making things complicated for everyone.

Our design goal with IguanaX is to make simple components that work for most people out of the box. But when something more complicated is needed, to make it easy to crack a component open and easily modify it to meet the need you have.

Expand

How are we going to get there?

We are starting by working with some helpful customers who are willing to share their code from Iguana 6 so we start to get a picture of ‘what is normal?'.

What is the set of components and configurations hits 90% of the use cases?

Expand
titleMy company uses legacy plugins - how do we solve this?

I would be happy to have a conversation with you.

Take a step back and think hard about what a plugin or client executable really is. It’s basically a means of allowing a programmer using a language like C# to push a message into an Iguana queue.

This is done through a number of layers:

C# Code → Stub code → DLL → Proprietary TCP/IP protocol in C++ → Iguana 6

Since IguanaX allows one to write fully fledged TCP/IP servers in theory you could replicate the proprietary TCP/IP protocol and without recompiling the C# code:

C# Code → Stub code → DLL → Proprietary TCP/IP protocol in Lua → IguanaX

It seems redundant though. In software simpler is always better in terms of less points of failure. This is the architecture I would recommend:

C# Code → Native web service call → Web Service component in IguanaX

A compromise could be:

C# Code → DLL → HTTP(S) calls → Web Service component in IguanaX

I think personally the bolded option makes the most sense. It offers the most control and extensibility since additional web service calls can easily be implemented - you’ll have much more control.