nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JobSubmit() return value in my application is null but myportal says fax was submitted

pshinohara

I am using the old com.premiereglobal.pt.xoa... API as this is legacy code currently being maintained.

My issue is on a fax JobSubmit. I send a document to be faxed but the return value from a JobSubmit call is null. I check the web portal to see the status of my fax request & it goes from delivering to completed. It gets sent to my test fax machine but my application is telling me otherwise.

I send it right away then check the return value to see the status (transaction id, etc...) so I can poll for that transaction status later on. But because I cannot get a transation ID from my submittal, I cannot track the status of the transaction.

I need to determine what a null return from JobSubmit(JobSubmitRequest) indicates & why the web portal says it was not in error. Thanks for your help.

Find more posts tagged with

Comments

thuneke

Did this just start happening and it was working before? Can you provide the job number?

pshinohara

I took over for a fellow who wrote this some years back...anyways, I believe it was working but when one of our customers was telling us that our check fax status indicator says some faxes never changed from the initial status condition of what we call "sending" but they can clearly see it on their web portal that it was successful, I started to investigate.

So I tested using our test account on http://test2messaging.easylink.com/soap/sync & found that the JobSubmit call returned null & came to the conclusion that since it failed, there is no way to look up the status of a transactionid that was never returned in the submit API call thus telling the user that it never changed from the "Sending" status... as if it were stuck.

The sample job numbers submitted in my testing are (obtained from myportal web page today 12/19/2012):

2198801

2195610

2195626

thuneke

Our logs show that we tried to return the request via asynch which requires a receiver on your side and there was no SenderKey in the request which is where we should send it to. That means it was submitted to http://test2messaging.easylink.com/soap/async

You should be using https and submitting to https://test2messaging.easylink.com/soap/sync

You should check your application to see if it is sending to synch or async. If asynch then your receiver may be going down. Also verify that the SenderKey is being supplied.

pshinohara

Thank you for the information. That solution was just what I needed.