Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi David --
Thanks for the reply; I'm glad to see this thread isn't completely dead (yet). 
A couple of caveats:
First, this issue does not depend on tFileInputDelimited -- my problem exists regardless of the previous component. I came across the original thread because I was tracking down a similar end result as the OP, and this post seemed to be the closest to my problem. I wasn't focused on tFileInputDelimited specifically.
Second, I'm aware that the NB_LINE value is an after-value, and that's really part of the problem. I don't want to find out the value during the run, but it's NOT coming across as an actual integer after-value. It's coming out, after the component has completed, as a null value, despite there actually being rows transferred. In the GUI, I can see that 2 rows are passed along, and I have verified that in the actual generated code too. But when I evaluate that component's NB_LINE variable immediately after the component, it has a null value. Very frustrating.
(I'm leaving that in for some context, so if anyone else reads this, maybe they're thinking the same thing...)
I had to re-write this reply because, in coming up with a simple example to show my problem, I think I found my mistake in the job design. The flaw is in that the tJava and tJavaRow components run asynchronously while in the main flow. As such, they don't see the final value of NB_LINE until that subjob finishes. At that point, they do see the correct value. If connected via an OnComponentOk link, then they work as expected. Here's the job I created to illustrate my question:
(Generates 2 rows of random data, shows in a table, and then prints out the row transferred count.)
In the tJavaRow_1 (top row) and tJava_1 (second row) components, the value of NB_LINE (from their previous tLogRow components) is always null. When I put a tJava component after the subjob, like in tJava3 (top row), then the value is reported correctly. What caught my attention was that the debug output I added was coming out before the tLogRow components finished printing their table (the output was above the table). In the subjob approach, the debug output was after the table printed. Clearly, things were executing at different times than I expected. Here's the output of the run:
As you can see, tJavaRow_1 prints the value of NB_LINE twice (expected), but instead of 1, 2, stop, it gets null, null, stop. The data is transferred okay, but since the tJavaRow_1 starts running at the same time as the full subjob, that global variable still has a null value at that point. tJava didn't help me, since it was doing the same thing. Then I had to go back and research why the Java components acted that way. In the Talend docs, it very subtlety mentions that tJava is really intended for subjob execution (hence why it worked in tJava_3 in the top row). tJavaRow was my go-to component, since I wanted it to be in the main flow, but because of when it fires off, it wasn't coming up with the right value.
I then kind of hacked it, in that I used the approach in the third row above. In that one, I made the one subjob process the rows, and then in the tJavaRow_2 component, I stuffed my target (the last row of data received) into a context variable, and then referenced it in tJava_4 for processing. I didn't like that approach, since it seemed fairly kludgy, and it was only a valid use case because I only cared about the last row transferred; if I needed several rows, it wouldn't work (or I'd have to tBufferOutput) for a later component that needed to work on the set. Here's the output from the third row approach:
Like I said, it worked, but not really the best way to do it. tJavaFlex, though, got my problem solved.
tJavaFlex offers three separate execution contexts. One for start, main, and end. I don't care about start and main, in this case. But end is perfect. I want to execute my Java code AFTER the previous component completely finishes. tJavaFlex allows that. Here's the new job:
In this version, my code is in the end block, and results in this output:
Just what I expected. NB_LINE has the right value, and I'm able to get that last line in the flow and do some custom code work on it. Brilliant!
I think I skated by in my previous Talend jobs by using tJava and expecting that I knew how it was executing. The reality was that I should have been looking at how and when the three Java components would execute. Once I did that, it was clear that tJavaFlex was a better solution.
By the way, I had first done exactly what you recommended in your #2 option, and I agree that's not the best choice. But, it did work. Using that internal variable, I could see it as it iterated up, so I was able to get my end result. It wasn't pretty or good either, which is what initiated my original reply. I wanted a "right" solution.
I know you probably didn't intend to take me down this path, but it worked out, and I learned more about how to use these Java components. My thanks for pointing me in the right direction. I'm hoping my lengthy last reply will be helpful to others in understanding the issue here.
Thanks!
Bruce