i have seen in some xsl that DP uses java.util.Date.new()
Can we use Java packages in our xsl??
Anyone Please help me out
Using the java packages i want to use sleep function which will make my xsl sleep for sometime
thx in advance
Re: DP supports java packages ????2008-11-18T15:46:55ZThis is the accepted answer. This is the accepted answer.There is absolutely no support for Java in DataPower products. There are some basic calls to Java primitive date/math functions that are recognized and redirected to equivalent DataPower extension functions (this was done for early compatibility with other XSLT platforms) but it is very limited.
You cannot sleep in SOA Appliance execution by design.
Re: DP supports java packages ????2008-11-19T08:41:52ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
i have a requirement like ,in case of backside connection errors i have to resubmit the message for 3 times
,each resubmission of message should be resubmitted exactly by 5min, difference time frame.
Any Help will be highly appreciated.
Re: DP supports java packages ????2008-11-19T17:12:45ZThis is the accepted answer. This is the accepted answer.
- SystemAdmin 110000D4XK
1) Upon failure, return an error to the initiating client and place the responsibility on them to retry the transaction after an agreed period of time. You can even customize the response error to include information like requesting the retry and the duration or time after which we would suggest a subsequent request.
2) Capture the back side error in an error rule and send the initial request to some OFF DEVICE retry facility. This could be any persistent storage mechanism that would be responsible for storing and retrying the transaction after a given interval. MQ would be a good candidate. You can send the request message to a queue, and after your sleep interval move it to another queue where a DataPower front side handler would pick it up and retry the request. If it fails, repeat the process. If it passes, route the service response back to the initiator of the request.
Because you are talking about such long durations between the retries, I am assuming that your initiating clients are not synchronous (i.e. HTTP) so some additional asynchronous processing should be fine. The bottom line here is that your device is not designed to manage long term transactions because it jeopardizes the performance and stability of the system - there is no persistent storage to keep them and you can't just buffer them in memory indefinitely without clogging the scheduled work queue of multi-step processing.
Hope this helps,