General Background
This article describes what to do when you need help from our support team. Following these tips and guidelines will ensure that your problems will be resolved as quickly and efficiently as possible.
Before Contacting us
Before you request support from our team, do the following first:
- Check the help center as it is frequently updated in response to customers issues.
Tip: search the help center to see if there is anything relevant to your problem.
- Determine whether the latest versions of Iguana and Chameleon have addressed your issue.
- See our download site to get the latest version.
- You can also download from our FTP site:
- Iguana is located in the http://dl.interfaceware.com/iguana/ directory.
- Chameleon is in the http://dl.interfaceware.com/chameleon/ directory.
If the manual and the most recent versions of our products do not resolve your problem, feel free to contact support at support@interfaceware.com. See the Support Tips below for how to contact us, and the information that you should provide.
Tips to improve the support process
Here are some tips that will be helpful to you if you need to contact our support team:
- Send all support inquiries to support@interfaceware.com, even if you have communicated with a specific support team member in the past. This is important, as a particular staff member may not be available on a given day.
- When you contact our support team, be sure to provide enough information to enable us to reproduce the problem.
- If you contact our support team, be sure to follow up on the resolution of the problem. That way, both you and our support team will be satisfied that your problem has been resolved.
The following sections describes the information you should provide when you contact us. This will help us resolve your problem as quickly as possible.
Collecting the Relevant Information
Before we can solve your problem, we need to be able to reproduce it. The information that you need to provide depends on the type of error you are reporting, see the following pages for details.
TCP/IP Issues [top]
These types of errors are very hard for us to diagnose without having remote access to your machine. You are in the best position to analyze the problem. Your best approach is to carefully carry out the troubleshooting procedures described in TCP/IP Socket Issues (below). If that does not work then you should follow the second procedure Reproducing TCP/IP Issues to provide us with the necessary information to help you to fix it.
Troubleshooting TCP/IP Socket Issues
This section shows you how to resolve TCP/IP Socket problems.
Get Some Background
You should have a good read of our transport section to understand the basics of TCP/IP and how HL7 is normally transmitted over this medium. Getting an understanding of this will make it much easier for you to diagnose problems.
Server Port Conflicts
Only one application at a time can listen on a given port number. If you pick a port number like 80 or 8080 (two ports commonly used by web servers) and you have a web server running on your machine, your HL7 server will throw some type of exception on start up because it will not be allowed to listen to the same port.
Ensure you are Connecting to an HL7 Server
If you are writing an HL7 client, be careful that you are actually connecting to an HL7 server. One problem we have seen was a customer thought they were connecting to a remote HL7 server but was in fact connecting to a web server running on the local machine. This was confusing because a web server will accept the HL7 message and generate an error response which an HL7 server will ignore. The web server will then break the TCP/IP connection.
Faulty LLP Implementations
The Lower Layer Protocol (LLP) is one of the most straightforward TCP/IP protocols in the world to implement. Unfortunately this does not stop some creative programmers from implementing it in their own special way.
The symptoms for when the LLP protocol has not been correctly implemented is when the HL7 Listener receives a connection from an HL7 client but does not seem to pick up any messages.
The best way to diagnose the problem is to follow the testing procedures outlined in the transport section of the manual with the MSOCS tool. This tool allows you to accept an arbitrary feed of TCP/IP data and then copy and paste the data into a file. This file can then be opened in a hexadecimal editor which you can easily assess if the LLP protocol has been incorrectly implemented. This process is described in detail in the transport section.
Note: For more information about LLP, see LLP – Lower Layer Protocol. Another tool that you may find useful is called Wireshark. Wireshark is a powerful tool used for protocol analysis and network troubleshooting. It is useful for testing the structure of different network protocols like TCP/IP and can be run on a variety of platforms such as Windows, Linux and OS X.
Reproducing TCP/IP Issues
If the troubleshooting procedure does not work, your next option is to create a very simple program which can reliably reproduce the problem and arrange for it to be sent to us. A good approach is to:
- Start with your message definition file.
- Generate a standalone client or server application from it using the code generator.
- Modify the application to recreate the problem.
This is a fast and efficient way to create an example test program.
If this does not work, we can arrange a remote session access to allow one of our support staff to examine your machine.
Other Issues [top]
For other issues like GUI and Iguana issues etc., please follow these instructions.
GUI Errors
To resolve a GUI error, you must provide:
- The sequence of steps you followed when you discovered the problem.
Note: screenshots are very helpful (a screen capture video can help if the steps are complex/obscure).
- The operating system and the service pack version that you are using.
- We also need the Iguana version information.
We will use this information to reproduce the problem.
Iguana Errors
If you encounter an error when running Iguana, you will need to provide us with a copy of the configuration file that you use:
- You will need to provide a copy of IguanaConfiguration.xml.
- We also need the Iguana version information.
This file can usually be found in the directory in which Iguana is installed (for example, C:\Program Files\iNTERFACEWARE\Iguana).
You will also need to provide a copy of any VMD file that is used by the channel that caused the error, plus a sample message.
Message Generation Errors
Message generation errors can be somewhat more difficult to reproduce. As a starting point, you should send us:
- Your VMD message definition file.
- An example of a message that you have generated with this file.
- A explanation of the problem you are encountering with message generation.
Other Problems
If you have a different issue please describe it clearly and supply any relevant background information.
FTP uploads to Support [top]
We have set up a Public FTP upload area, if you need to send us large files, such as logs, crash dumps etc. that are too large for email.
To prevent file corruption make sure you’re using binary transfer mode when uploading files (and when passing files internally).
Note: To ensure confidentiality, the following security restrictions are applied:
- Files can only be uploaded
- Files cannot be listed
- Files cannot be viewed
- Files cannot be downloaded
- Files cannot be deleted (or overwritten by a file of the same name)
Tip: Because files cannot be deleted/overwritten you cannot upload the same file twice.
If you need to upload the same file again, then you must change the file name, perhaps from “…crash.dmp” to “…crash2.dmp”.
File naming convention for uploaded files
Files must follow the naming convention below to ensure they’re properly identified.
The naming convention is:
- YYYY-MM-DD[_#TicketIfKnown]_Company_Name_OriginalFileName.ext.zip
- For example: 2000-12-24_#1234_Interfaceware_JohnDoe_crash.dmp.zip
Warning: Files that do not follow our naming convention are difficult for our support staff to identify — and can cause delays in processing your help ticket.
If we cannot identify your file you may be requested to upload a new copy that follows our naming convention.
Note: We recommend that you combine related files like crash dumps and service logs etc. into a single zip archive before uploading. See Iguana Crash Reporting for more information.
FTP Server and login credentials
- FTP Server: ftp.interfaceware.com
- User name: upload
- Password: (your full e-mail address)
Note: The upload user uses anonymous ftp.
Terminal Script example
This script should work using any terminal window, like cmd on Windows or Terminal on the Mac, etc.
These are the steps (commands shown in red):
- Connect to the server:
ftp ftp.interfaceware.com
- Enter the user name: “upload”
- Enter your email as password:
Password: <password not shown>- Anonymous access is granted.
- Access is restricted (you cannot see or delete files)
- Binary mode is automatically used.
- Use the put command to upload the file:
put 2000-12-24_#1234_Interfaceware_JohnDoe_crash.dmp.zip
- Logout:
bye
Your terminal script will look something like this:
$ ftp ftp.interfaceware.com Connected to ftp.interfaceware.com. 220 iNTERFACEWARE FTP: Name (ftp.interfaceware.com:parallels): upload 331 Anonymous login ok, send your complete email address as your password Password: 230 Anonymous access granted, restrictions apply Remote system type is UNIX. Using binary mode to transfer files. ftp> put 2000-12-24_#1234_Interfaceware_JohnDoe_crash.dmp.zip local: 2000-12-24_#1234_Interfaceware_JohnDoe_crash.dmp.zip remote: 2000-12-24_#1234_Interfaceware_JohnDoe_crash.dmp.zip 229 Entering Extended Passive Mode (|||26387|) 150 Opening BINARY mode data connection for 2000-12-24_#1234_Interfaceware_JohnDoe_crash.dmp.zip 100% |*****************************************************************************| 16384 KiB 873.61 KiB/s 00:00 ETA 226 Transfer complete 16777216 bytes sent in 00:18 (866.72 KiB/s) ftp> bye 221 Goodbye.