You can THROW or set any error while Quitting,

Both should disable, if E=D.

One quick question - have you restarted you operation after putting this Logic.. The code changes will only be effective only after operation is linked to new JOB.

You can also, try debugging your code attaching corresponding job of operation in studio.. there is no reason this should not work.

Retry Interval- No. Of seconds a business operation  job wait before doing next retry

FailureTimeOut - Total no. Of seconds a business operation Job keeps trying connecting destination.

We should keep this always greater that retry Interval. 

ConnectTimeOut - 

In case of FTP, a business operation job tries to connect FTP server till ConnectTimeOut for each attempt.

In case of TCP, a business operation job tries to connect to remote TCP listener till ConnectTimeOut for each attempt.

Ideally this has nothing to do with retry Interval, but we should take a logical call while setting this value and keep always less than FailureTimeOut.

No. Of reties may depend on the combination of these three values.

Hi Basem,

Yes, you can do that, but you need to make sure that you do not change anything in original Message Header. You should only use message header to retrieve message body.

Status, sessions etc are stored in message header, with message body class name and message body ID.

So in Ensemble, you can create a Webservices which will accept request. And request may contain message body class name, source and Target. Now you will query in Ens.MessageHeader with this params and get message body IDs, and you already know class name. From message body IDs you can get all the messages and can construct a response for your Webservice.

Your Vendor can call this Webservice, whenever he wants to PULL all the details of queued up messages.

I understand, a bit of coding involved doing this, but this how I think you can achieve the requirements.

Please let me know if you find any better way doing so.

Regards,

Sourabh

Hi Jimmy,

For such scenario, we should $$$Trace.

We can covert HTTP request to string and pass it in trace. $$$Trace can take string or anything inherited from ens.message.

In Production, in the corresponding Business Operation, find Enable trace setting. 

Then for next transaction, you can see the httprequest in trace.

Don't forget to disable the trace option once you are done, as we should try this only for debugging purpose.

Regards

Sourabh