[Rick Martin]

You would pass the data in the Args section on the TPS Properties page where you defined the Java Class to call, the same way you would pass args to a TCL TPS proc.

The second method is saying you can pass anything you like in the USERDATA (metadata) attached to the message.

[Rick Martin]

We’ve been getting this error for quite some time and have so far not found a fix.  If anyone knows of one, please let us know.

[Rick Martin]

Hi David,

Our solution works regardless of file type.  It opens the file in binary mode and base64 encodes it.  Here’s a code snippet:

   set fi [open $fileName r]

   fconfigure $fi -translation {binary binary}

   set en64Var [encode [read $fi]]

   close $fi

Rick

[Rick Martin]

We’ve also Base64 encoded the PDF file directly into an OBX segment using the encode command in a TCL proc and put the encoded string into OBX.5.

OBX|1|ED|PDF^filename.pdf||

The other side simply needs to rehydrate the PDF by decoding the data in OBX.5.

[Rick Martin]

Hi Jim,

We’ve interfaced with a few BizTalk instances.  No real TCP/IP problems, but BizTalk does have it’s own quirks especially with how it handles acknowledgements and things like trailing pipes.

Rick

[Rick Martin]

Hi Andre,

Long time no talk!  Are the embedded characters encoded in the XML like this: ?

I had posted something about that on this board last year.  In my case, the parser was treating those sequences as actual carriage return/line feeds.  I ended up having to strip them from the XML document before processing.  If you need them in the final document, you will probably have to substititute them with something else prior to processing.

Rick

[Rick Martin]

SP2 is actually a requirement for 5.5REV1.

[Rick Martin]

Try removing the braces around your arguments:

sendEmailMessage cloverleaf@here.com rlp71@some.com xx.xx.x.xx subject body

You may have to put quotes or braces around any argument that contain white space like your subject or body.

[Rick Martin]

We also have a TCL proc which uses the mime and smtp TCL packages (which you would have to download and install); this assumes you have SMTP access to your mail server.

Code:

######################################################################
# send_simple_email – sends email using smtp/mime packages
# Args: recipients comma-separated email addresses
#       subject   message subject
# body       message body
# Returns:  nothing
#
proc send_simple_email {recipients subject body} {

   package require mime
   package require smtp

   set token [mime::initialize -canonical text/plain -string $body]
   mime::setheader $token Subject $subject
   smtp::sendmessage $token -header [list From “FromName “] -header “To $recipients” -servers “mail.domain.com”
   mime::finalize $token

   return 0
}

[Rick Martin]

Hi Dave,

Don’t know if this helps, but our testing of 5.5 Rev1 on Windows Server 2003 SP2 has gone well.

Rick

[Rick Martin]

Julie,

We’ve experienced similar failures (Windows 2000 and 5.3).  We were also told to remove the directories from scanning by AntiVirus software, which we did, but still experience random failures.

For those that have removed these directories from backup and antivirus scanning; how are you getting backups for disaster recovery purposes?

[Rick Martin]

Our environment is Windows Server at the server end and Windows XP at the client end.  Since Windows Server limits you to 2 adminitrative logons to remote desktop, that is the problem I’m trying to solve – having the developers run the client on their desktop/laptop while VPN’ed in to the network.

[Rick Martin]

Still no luck getting the testing tool to run over the VPN.

I can copy the hcixlttest command from the testing tool window, but what command line are you talking about pasting it into?

If I paste it into a Windows Command Prompt window, I get an error that tcl83.dll is missing – this is a client-only install.

[Rick Martin]

Yep, I’ve read those posts.  They seem to alude to some type of network filtering.  We’ve gathered a network trace from the server and client.  When on the LAN we can see the communication going back and forth, but when on the VPN, we see the request go out, but nothing come back.

On LAN:

Request goes from port 4202 (probably dynamic) to 1052

Response comes back from 1389 to 4203 (probably dynamic)

On VPN:

Request goes from port 4985 (probably dynamic) to 1052

No response come back

The use of ports 1052 and 1389 seems strange to me.

[Rick Martin]

I know this is an older post I’m replying to, but is anyone using the Cloverleaf client on Citrix?

We have a need for multiple (more than the 2 we get with Windows Server) remote developers to be developing using the Cloverleaf client and we’re having the known problem with the Testing Tool not working across the VPN.  I’ve got our network folks trying to figure out what’s wrong, but I’m looking for alternatives.

[Author]

Replies