Return value of pdupoc_write TPS

[Bakha Nurzhanov]

Hi there,

I am developing tcl script to implement custom protocol (SFTP). It is going to be outbound thread (in most cases). My question is the following: are there defined return values which I can return from my tcl script to communicate to the thread whether file transfer succeeded or not (similar to what Fileset-FTP reports back)?

Bakha

Topic

[Jonathan Hamilton]

When you disposition the message as CONTINUE it is assumed that the procedure completed successfully.  If it didn’t you need to disposition as ERROR.

A quirk/flaw, with QDX5.3, in the UPoC Write TPS is you cannot use OVER or PROTO dispositions to requeue a message when a failure is encountered.  If you need this type of functionality you have to set a flag in the metadata USERDATA field, disposition the message as CONTINUE from the UPoC Write TPS, then use a procedure in the Send OK TPS to validate if the protocol flag indicates successfull or not.  If the flag is not successfull, disposition the message with PROTO to requeue the message at the head of the queue.  We typically trigger an alert then shut the thread down to allow the error time to resolve, but that is optional.

[Charlie Bursell]

Jonathan:

Why would you call this a quirk/flaw?  In this context the UPoC is a driver and the message has been delivered to that driver.  What other protocol driver can you OVER or PROTO a message from?

Charlie

[Bakha Nurzhanov]

Jonathan – it looks like I should not use KILL in protocol write TPS, I get an error message when I try to use it:

[upoc:tps :ERR /0:tps_proc_name] [0.0.messageId] Unsupported disposition from protocol write TPS: KILL

So I am still wondering if I need to return some sort of ERROR code or value using tcl return statement (in addition to the DISPOSITION)?

Bakha

[Jonathan Hamilton]

Charlie,

I played around some more and found that the ERROR disposition requeues the message instead of writing the message to the error database.  I never really tried it since I didn’t want the message errored.  So knowing that, you are correct in not needing OVER or PROTO.

Jonathan

[Lin Yue]

Just to be sure someone who reads this thread sees this:

If you return from your UPoC protocol write proc with:

– CONTINUE: Send OK Procs will be called

– ERROR: Send Fail Procs will be called

You can use this very nicely to KILL a message you do not want.  Simply set the Send Fail Outbound Procs to hcitpsmsgkill.  

If you need more functionality like PROTO (or sending the message to the error database) you can just create your own proc to do that and set the Send Fail Outbound Procs to that.

[Author]

Replies