[Tony]

So we have issues lately where files just pile up in integrator, and we have to restart to get them to all go through. Meanwhile, we are receiving anywhere from hundreds to thousands of trace entries a day that say the following -

procengine(procengine(ta_xfb)) XFB.CancelTransfer: GIK error

We've been told that this was related to the XFB connector, and that it is a known weak-spot, but I'm really hoping to do something about it. Has anybody else battled issues with the XFB connector failing on you? An example of one of our flows would be an XFB Receive from Gateway, A Decrypt and rename, and then an XFB Send method back to gateway. What frequently happens though is that the XFB receive method gets the file, and then nothing happens with it.

Any thoughts?

T.Lloyd

[basvandenberg]

So we have issues lately where files just pile up in integrator, and we have to restart to get them to all go through. Meanwhile, we are receiving anywhere from hundreds to thousands of trace entries a day that say the following -

procengine(procengine(ta_xfb)) XFB.CancelTransfer: GIK error

We've been told that this was related to the XFB connector, and that it is a known weak-spot, but I'm really hoping to do something about it. Has anybody else battled issues with the XFB connector failing on you? An example of one of our flows would be an XFB Receive from Gateway, A Decrypt and rename, and then an XFB Send method back to gateway. What frequently happens though is that the XFB receive method gets the file, and then nothing happens with it.

Any thoughts?

T.Lloyd

Do you have separate commadapters (and processing engines) for your incoming and outgoing traffic (from an Integrator perspective)?

Regards,

Bas

[MoefGaGa]

I seriously would like to advice to use the ftp connector between both components and read from the local file system (not opening an ftp connection to gateway).
This approach has the following advantages:
1. The transfer and transformation steps are totally asynchronous. Integrator can go down but Gateway can still receive files and store them locally without throwing transfer errors.
2. In case Gateway is overloaded with files (somebody sending a flood of files), my proposed solution will not throw in then thousands of files to Integrator which can go down due to this. Instead, if properly created, the ftp script used can only pick up a certain number of files for each polling of the shared directory
3. You can set up different flows each having their own receiving schedules. WIth the Gateway connector you always send the incoming files immediately to Integrator and maybe thisis not what you want.

For the above reasons, I decided to not use the Gateway connector but instead to use an end of transfer unix move script combined with Integrator's ftp connector which polls the locla filesystem.
The reason why we used the polling of the local filesystem is that we don't want loggings to apear in Gateway log or Sentinel XFBLOG of the polling of Integrator which would be in case the ftp connector connected via FTP to Gateway. With an end of transfer script of Gateway combined with local polling in Integrator, this was avoided.

[Tony]

Thanks for the response, I'm VERY intrigued by what you're talking about here. It sounds like it would be a lot of work and a big implementation, but given the reliability of the xfb connector (or lack thereof) any solution that's viable is worth exploring. In the environment I'm working with currently, almost all files are routed by default from Gateway to Integrator for processing. From integrator a good majority are sent back to Gateway, which is where we seem to be having all of the trouble. Would this solution then use the FTP connector to send all files back and forth between Gateway and Integrator? Have you seen it side-by-side vs something using the XFB connector? Also, when you say "Axway Belgium", are you saying that in Belgium Axway sets up the integrator/gateway connection differently than they would here?

Thanks for the response, looking forward to hearing back!!!

I seriously would like to advice to use the ftp connector between both components and read from the local file system (not opening an ftp connection to gateway).
This approach has the following advantages:
1. The transfer and transformation steps are totally asynchronous. Integrator can go down but Gateway can still receive files and store them locally without throwing transfer errors.
2. In case Gateway is overloaded with files (somebody sending a flood of files), my proposed solution will not throw in then thousands of files to Integrator which can go down due to this. Instead, if properly created, the ftp script used can only pick up a certain number of files for each polling of the shared directory
3. You can set up different flows each having their own receiving schedules. WIth the Gateway connector you always send the incoming files immediately to Integrator and maybe thisis not what you want.

For the above reasons, Axway Belgium decided to not use the Gateway connector but instead to use an end of transfer unix move script combined with Integrator's ftp connector which polls the locla filesystem.
The reason why we used the polling of the local filesystem is that we don't want loggings to apear in Gateway log or Sentinel XFBLOG of the polling of Integrator which would be in case the ftp connector connected via FTP to Gateway. With an end of transfer script of Gateway combined with local polling in Integrator, this was avoided.

[Tony]

Do you have separate commadapters (and processing engines) for your incoming and outgoing traffic (from an Integrator perspective)?

Regards,

Bas

It doesn't look like it, for XFB.Gateway in task manager we just have one Gateway Transfer Adapter Task and one Gateway Transfer Adapater Classifier. Should there be 2 of each, one for inbound and one for outbound?

[MoefGaGa]

My proposed solution (XFBgateway with an end_of_transfer move script) together with a local polling by Integrator using the FTP connector of Gateway is setup at a big (wxorld's biggest) car manufacturer as we encountered the same issues you were talking about at this customer as well as a Bank&Finance customer in Luxemburg.

The only thing that is NON-STANDARD is the end_of_transfer script we use.
But this script will be activated as follows:
move_end_of_transfer_script.pl -i <source filename>-o <target filename>
and inside the (perl) script we do the following:
$source_filename = $ARGV[1]; #this is the second argument as the first is -i
$target_filename = $ARGV[3]; #this is the fourth argument as the first is -o
rename($source_filename, $target_filename);
If this is simple or not, I let you judge yourself :-)

So my proposed solution is not at all a complex solution but a working and simple solution that has a lot of advantages.
The only weakness of my solution that is sometimes happens that the local FTP connector does not poll the local directory properly and we have to restart the transfer connector in that case.
SP4_P7 should solve this issue. However, I did not yet install this latest patch so I cannot say anything about it.

Even if the XFB connector would work correctly, I would not like to use it as I want both components to be loosely coupled. As it works now, it is hardly coupled. Also the fact you can not have different integrator schedules to receive the files from gateway is something I don't like at all. So writing to a local shared folder will solve all of these issues.


Note: the rename in the script does not show up in the XFBTransfer. If you want this to appear in Sentinel as well, then the Universal Agent should be used. But that is another topic.

Kind regards.

[Rhenus ICT Servi...]

procengine(procengine(ta_xfb)) XFB.CancelTransfer: GIK error

We've been told that this was related to the XFB connector, and that it is a known weak-spot,

Did you ever open a case on the Axway supportsite?

This sounds like a bug that should be fixed, especially since it's a known weak-spot.

[Tony]

Did you ever open a case on the Axway supportsite?

This sounds like a bug that should be fixed, especially since it's a known weak-spot.

Oh you better believe it We've been getting errors related to this for months now (30,000+ and counting) and have all but nailed it down as the root cause for our production outages...the most recent of which happened at 3:00 a.m. friday after Thanksgiving. A recycle of integrator fixes it, but the guys working in the middle of the night dont know this and are trying to research it because the trace errors always exist, none of the services go down, and to the untrained eye it looks like things are going ok. Unfortunately we haven't gotten much feedback from support except for asking for trace entries and whatnot.

Also, I realize that this is integrator V3 forum and we're on Integrator V2...the XFB connector is the same but I dont know if the other solution proposed by Moe is viable. I dont think the integrator V2 forum was here when I posted, or else I completely missed it.

Thanks all!

[basvandenberg]

Based on a request from Tony this topic has been reopened to share a solution that worked for him.

Oh you better believe it We've been getting errors related to this for months now (30,000+ and counting) and have all but nailed it down as the root cause for our production outages...the most recent of which happened at 3:00 a.m. friday after Thanksgiving. A recycle of integrator fixes it, but the guys working in the middle of the night dont know this and are trying to research it because the trace errors always exist, none of the services go down, and to the untrained eye it looks like things are going ok. Unfortunately we haven't gotten much feedback from support except for asking for trace entries and whatnot.

Also, I realize that this is integrator V3 forum and we're on Integrator V2...the XFB connector is the same but I dont know if the other solution proposed by Moe is viable. I dont think the integrator V2 forum was here when I posted, or else I completely missed it.

Thanks all!