hcitbllookup vs switch statement

You should be able to test that yourself.

Write 2 procs one with switch and one with Table Lookup.

Include some measurement code (look to the clock command) and echo out the metric.

Run the same test against both and see the difference.

I recall the Table handling is really quite efficient both in storage and execution (inside the engine particularly).

If this is a large table subject to frequent changes then of the 2 solutions the Table is probably easier to maintain by anyone.

If the data is available externally then an even better solution is to have someone else maintain the data then reference that. There are a number of ways to do that including exporting from the source to a delimited file and building a lookup table from that. Other have loaded to SQLite, and some have even referenced such data directly from the source if it is a DB. Yet others have other solutions.

Personally I don’t write any more Tcl than I need to so in this situation I would lean towards a lookup table based solution (inside an Xlate if possible). But that is me.

I get on this soapbox from time to time  😀

At least 60 – 75 percent of the life cycle cost of any software project is in the maintenance!

Think about the purpose of an integration engine.  Surely any point to point interface written in any language for a specific purpose would be much more ergonomic than any off the shelf integration engine.

However, consider which is more maintainable if a change occurs.  Would it be the GUI based system where you simple make a change or a piece of software?  That software must be understood if not written by you (sometimes even if written by you), edited, tested, regression tested, and even sometimes go through source control and QA.

Sometimes, for weird stuff, we have no choice.  That should not ne the norm.

Nuff said.  Off the soapbox now.

Hi Greg.

We have previously compared performance of TCL code with and without table lookups and found little extra cost.

We have now moved a lot of tables to CSV files. This enables an application support group to ‘own’ the table (spreadsheet, XLS format) and we just ‘save as CSV’ and migrate.

If you do use this, be very careful as the spreadsheet load of a CSV file will remove leading zeros from the columns!

Greg,

A couple of considerations for your testing:

Do your testing inside the engine (after all this is probably where you will actually be doing the work).

For the Table measurement, start your test after the first lookup as that triggers the loading of the table in memory. After the first message all lookups will be done from memory.

I’ve found Cloverleaf’s table lookup to be very quick, so I wouldn’t code table-type info directly into a TCL procedure to make it faster.

In addition to the clock command that Jim mentioned, you can get better resolution with the time command.  

When I’m doing time comparisons, I’ll usually set it up to run a large number of executions and then average the values.  Comparisons of timing with one-iteration values can be skewed.  I also think that table lookups from the Cloverleaf TCL command prompt will give you valid results.  I don’t think you need to run them in the engine itself for a comparison like this.

Here’s timing on a table lookup:

A proc that does the same thing with a switch is not much faster:

Charlie’s point about maintainability is a good one.  If the info you’re looking up changes frequently, use a table – or some other method that’s external to the code.  If it doesn’t change, or does so very infrequently, it’s OK to keep it inside your interface code.

If your data contains two columns, a table works well enough.  If it contains more than two columns, or if you need bi-directionality without a unique one-to-one relationship in both directions, you’re out of luck and need to use another tool.

I, personally, like SQLite because of it’s functionality, it’s performance  – and its price – so, I most often will use it instead of a Cloverleaf table.

Yes: maintainability is most import, in my opinion.

You can use tables if you need more than 2 columns/fields; see screenprint 1.

Another way to get the multiple values in column B is to use a delimiter that won’t be in the data, like ^. Of course then you have to split the result, but that’s how I did one table.

Hi,

In Xlate can I use ITERATE over list variable (i.e. @list). this variable holds value returned by tcl proc.

Pls refer attachment for more details.

Any help will be appreciated.

Thanks,

Kapil

Kapil,

I’m not sure I fully understand your question, but you can essentially manipulate the value of any iteration variable by referencing it with the $ nomenclature; i.e. COPY =1 –> $%l1

Thanks Jim for reply!

Let me elaborate the problem statement….

I have declared temp variable in xlate called ‘@mylist’. this variable holds the data in list format e.g. {1 2 3 4 5 6….}.

I tried using ITERATE command in xlate to iterate through the above list

i.e. In ITERATE Command I filled in below attribute values;

Type :lits

Basis : @mylist

Variable : %l1

Now when I tried echo values of ‘%l1’ variable I am not getting expected output. it prints value as “@list”.

so wanted to know is it supported in cloverleaf do iterate over variable?

Pls feel free to reply in case you have further question about problem statement.

Regards

Kapil,

Cloverleaf 6.0 doc iindicaattes you can do what you want – but I hav not gotten it to work. It appears you are on even a leter release and it is not working there either.

I think I undeerstand what you want and I wwill try to share how I do that.

In your ITERATE set your basis to ‘0 1’.

We have a proc which pops off the top element of a list and returns that element plus the remaining list.

So initialize a temp variable (let’s use @elem) before the ITERATE.

Execute Tcl (inline or a proc) to pop off the top element of @list and return @elem and @list.

Inside the ITERATE check @elem eq @null (if it is the list has been fully processed) and COPY =2 to $%l1  (this effectively ends the ITERATE since the counter is now greater than the number of elements in the basis)

ELSE (means there is more in the list) COPY =0 to $%l1 (this resets the ITERATE to the start) and do whatevvr you want with @elem (like COPYing to an outbound field, etc.).

If you would like thee proc we use to pop off the list element email me.

Sounds good idea! 🙂

Yes I am using CLR v6.1

I will try suggested trick and let you know how it goes.

Once again many thanks!

Kapil

The List ITERATE ‘trick’ is not mine. Another Clovertech member shared this some time ago.

Sadly I do not remember who so I cannot give proper credit.

The proc was written for us by Don Ramey a former employee and all around goood guy.

Oh oh! A chance to reignite my five minutes of fame!

It was 8 years ago when… https://usspvlclovertch2.infor.com/viewtopic.php?t=2213

🙂

Hi all,

Regarding the post on using a temp variable (e.g. @var) as a basis for an iteration, I can inform you about the following:

According to the documentation you should be able to use a temp variable as a basis for an iteration.

However we tried this and it did not work.

We registered a call for this in InforXtreme Case number: 8849524

Infor replied that this is a bug and it is planned to be solved in Cloverleaf 6.2

AR number for 6.2: AR12925

Kind Regards,

Marc Pleijers

Robert – Sorry I could not remember you posted this – I don’t use this often but it realy comes in handy.

Marc,

Hopefully when they fix that you will get the value of the counter when referencing it and not the positional value of the element of the list. If fixed correctly, this will be a welcome functionality.

with regards to

That sounds familiar to me and I sort of recall I had to match the construct of the variables typically used for iteration.

So for a list iteration I might use a temp variable like $%l9, for a group iteration I might use a temp variable like $%g9, for a segment iteration perhaps a temp variable like $%s9.

Unfortunately, this restriction does take the use of a meaningful temp variable off the table, which is more desirable.