| Author |
Message
|
| paustin_ours |
 Posted: Thu Jan 07, 2016 10:16 am Post subject: connect direct |
 |
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
i am looking at the infocenter and other resources online. trying to integrate connect direct with message broker. I see in the infocenter where a CDoutput node can be used to serialize an output to a file and then intiate transfer via the connect direct server.
i want to just kick off a file transfer without writing it out via cdoutput, just want to possibly send a trigger message to the underlying cd server to start the file transfer, is this possible? if it is, how do i know once the transfer is complete?
i agree i have to do more reading but just wanted to reach out for some help.
thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jan 07, 2016 10:58 am Post subject: Re: connect direct |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| paustin_ours wrote: |
| i want to just kick off a file transfer without writing it out via cdoutput, |
Why? If you're just trying to use IIB as a control mechanism for C then that's a horribly cumbersome way to do it and you're better off using the inbuilt tooling.
| paustin_ours wrote: |
| I just want to possibly send a trigger message to the underlying cd server to start the file transfer, is this possible? |
IIB could use any of the APIs or other control mechanisms C supplies like any application. I repeat my above comments.
| paustin_ours wrote: |
| if it is, how do i know once the transfer is complete? |
You don't. The point of C is to let it handle the file transfer; conceptually the same way you'd hand off a message transfer in MQ. If you want to know how C's doing with the file transfer, the best way is to ask C in the same way you'd use the MQ tooling to check for messages.
This really sounds a lot like you're trying to control C with IIB flows; something sends IIB some kind of "file in place" message and IIB kicks off the file transfer. This is much better done with the facilities inside C, and if those are insufficient for your use cases, buy Sterling Control Center (or whatever it's called these days) rather than rolling your own in IIB.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Thu Jan 07, 2016 4:45 pm Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
| Quote: |
| This really sounds a lot like you're trying to control C with IIB flows; something sends IIB some kind of "file in place" message and IIB kicks off the file transfer. This is much better done with the facilities inside C, and if those are insufficient for your use cases, buy Sterling Control Center (or whatever it's called these days) rather than rolling your own in IIB. |
that is exactly what I am trying to do, this is part of a bigger process flow. Once I get a file in place message, the flow reads the message and looks up the destination and should perform the file transfer.
I guess i will have to make a java api call from JCN
can you please shed some light on the drawback of using CD this way? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jan 07, 2016 10:53 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| paustin_ours wrote: |
I guess i will have to make a java api call from JCN
|
If you mean do some actual I/O from Java inside a JCN then the general consensus around here is
Don't do it.
If you are calling some other software that runs in a different process then you should be ok. Just be careful.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 08, 2016 5:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| paustin_ours wrote: |
| can you please shed some light on the drawback of using CD this way? |
Firstly you're reinventing a wheel. SCC does exactly what you're describing, and comes with a user-friendly front end to manage the file transfers. It also has capabilities for administering snodes, pnodes and netmaps.
Secondly you're introducing state into IIB. So you get a message saying the file's in place and trigger the transfer. At best, you're now repeatedly querying the agent to see if the transfer worked. At bad, you're in retry land because the network's gone wibble and the agent can't communicate with the target. At worst, you're trying to signal whoever sent you the "file in place" message that a) the file isn't in place b) it's in place but they didn't release the file lock and the agent can't move it c) it's there but it's empty d) etc.
That's a lot of code for a lot of possible situations. And you're on the hook when it doesn't work.
If this is part of a bigger process flow, get whatever's orchestrating the process to manage the transfer. Unless you're using IIB to orchestrate the process flow in which case all hope is lost; that's managing file transfers on steroids.
-
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| paustin_ours |
| Posted: Mon Jan 11, 2016 4:16 am Post subject: |
|
|
Yatiri
Joined: 19 May 2004
Posts: 667
Location: columbus,oh
|
Thanks for the pointers. My reading about this lead to MQ FTE and also read a blog that CD and FTE are now combined into just one product and the announcement came in 2014. Not sure if this is true.
Now is FTE better suited for such transfers driven by a broker flow? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 11, 2016 5:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| paustin_ours wrote: |
| Now is FTE better suited for such transfers driven by a broker flow? |
No it isn't. For exactly the reasons I gave above. Firstly, MQ FTE and Connect:Direct were two IBM products that competed in the same functionality space (because they were originally developed by external companies and purchased by IBM) so the issues are the same. Secondly, the problem (as I tried to articulate above) is not the file transfer, but attempting to manage and administer it using a broker flow. This is a bad design pattern as I tried to explain.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
