Hello Experts,
There was a transaction in trading networks which was due to the below
“Parameters xmldata, $filestream and $filedata are all missing. One of these must not be null.”
The reprocessing of the transaction didn’t succeed but the resbumit of the transaction was done succesfully…
The following are observations for the failed and its reprocessed transaction
→ The storage type is showed as “tspace” - When does this happen?
->The storage reference “BasicData:data=>>>BasicData:filename=IS_HOME/instances/default/largedoc/72DocRes.dat,inUse=2621971,reserved=2621971<<<<<” : What does this mean?
However when the same transaction has been resubmitted it has been successfully processed.
Here the storage type is now “text/xml”
Can someone provide your thoughts on this. What could be the reason the service succeeded when resubmitted and failed when reprocessed and in original transaction
Regards,
Arun Cholleti.
Hi,
Where in the TN flow was your resubmit made? If it is on a file processing trigger (from the message it seems so) it has to handled the file as processed by the file port, which is unlikely at that point.
I usually on have a very slim handler service as the file port service handler so I can than dispatch a full pipeline to a backend processing service, which can more easily be resubmitted. (unless you have large files and/or use streams - which is your case).
[btw, IS writes the pipeline in serialized text format on the log, which is what you are seeing as BasicData:data=>>>BasicData…]
I very much dislike file processing, essentially because of the fragility of the process, and luckily SAG has brought ActiveTransfer to the market, which deals with all these questions in a much more controlled manner.
Basically, I think you may have to increase the robustness of the file handling. When possible, one approach is to move a file from the INBOX folder to the PROCESSING folder, where it can be reprocessed, slimming down the INBOX processing services (which mostly only move files). This way you separate you first TN task in two, separating the responsibilities.
Best Regards,
Thanks for responding Gerardo
My apologies if i didn’t post the question clearly.
A TN transaction was failed due to the service invoked by the processing rule has failed.(The failure of the service occured due to the below error message
exception: “Parameters xmldata, $filestream and $filedata are all missing. One of these must not be null.” )
Which clearly mentions that the input was not passed to the flowstep:xmlStringToXmlNode in the invoked service by processin rule.
So when the same failed transaction was REPROCESSED the service failed again with same exception.
However, when the transaction was RESUBMITTED it succeeded.
My question is why the service failed when it is REPROCESSED and why did it succeeded when it was RESUBMITTED(Note :no changes made to the service).
is it somehow related to the storage type of the document which in reprocessing and original transaction case here is “tspace”? Just wondering.
What is the difference here
-Arun Chollety.
Hi Arun,
Did the same processing rule handle the document when it was originally processed, reprocessed, and resubmitted and was the same processing service invoked in all cases?
Thanks,
Mary
Hello Mary,
Yes, it is the same service which was invoked in the case Resubmiited and reprocessed case.
When the resubmit happened the TN creates new instance in which the same processing rule was invoked which in turn invoked the same service which was invoked in reprocessing case(failed case)
The storage type in reprocessed and original transaction case was “tspace”