We need to interlink our local CA Service Desk with another Service Desk Software (ARS Remedy) running elsewhere. The coupling includes the interchange of attachments in both directions. We are using PAM as the middle layer, taking Requests from the remote side and forwarding them to our CA Service Desk as well as the other way round.
The ARS Remedy system interfaces with PAM by calling "executeProcess" via the SOAP API. The attachment data is given Base64 encoded as a process parameter.
This seems to be impractical by several reasons:
1. The attachment data, which might be quite big, is held as a process variable inside memory. We fear that this might give memory problems later on.
2. The attachment we get is base64 encoded. It needs to be uploaded to our CA Service Desk using the SDM SOAP call createAttachment. For this, it needs to be decoded in memory. This might cause further memory problems later on.
3. Instead of decoding the file in memory, it is also possible to decode it using commandline tools. For this it is necessary to write the attachment data to the local filesystem. But the "Write File" Operator seems to have problems writing big files. As a workaround it is possible to write the file in small chunks, but this takes a considerable amount of time.
All in all i am not happy with the current solution, maybe there is a better way to handle file attachment with PAM other then using process parameters?
Can ARS Remedy store the attachment somewhere that can be accessed using a URL then just pass the link?
Our first idea was to use an intermediate FTP server and use a two step based transfer (1. save the file to the FTP server, 2. send the file location with the request to PAM for further processing). This is somewhat like the URL base approach suggested by you.
Unfortunately the "2-step" approach is not acceptable by the other side, they insist in transferring the attachment data in one request.
At the moment we build a tomcat webservice. This webservice will get the SOAP request, puts the attachment into the SDM attachment store, replaces the attachment data with the now available attachment id and forward the request to PAM. A similiar mechanism exists for the other way round.
But this does not feel "right".