DisplayInstance.jsp gives 404 when viewing instances in BPEL Console

Question

Using soa suite 10.1.3.4 on WL 9.2
In the /BPELConsole app, deployed bpel processes list their instances on the instances tab. But clicking on any of the links for the instances gives a 404
https://our_host:our_port/BPELConsole/default/displayInstance.jsp?referenceId=bpel://localhost/default/process_name/30054&mode=manage
Removing the parameters from the above to the following resolves correctly and just re-displays the page at
https://our_host:our_port/BPELConsole/default/instances.jsp
I don't see any errors thrown in the "SOA_HOME"/bpel/domains/default/logs/domain.log or in the WL managed server logs other than the actual 404 itself in the WL access log:
[14/Oct/2009:10:08:04 -0400] "GET /BPELConsole/default/displayInstance.jsp?referenceId=bpel://localhost/default/process_name/30049&mode=manage HTTP/1.1" 404 1214
I've checked the esb_parameter table, and the dt_oc4j_host & dt_oc4j_http_port rows are correctly set to the server's host & port
Although all of our WL instances use explicit ListenAddress values which match their host names, I'm pretty sure it's not the localhost portion of "bpel://localhost" as our other environments show the same syntax in their BPELConsole pages but correctly display the instances. And /etc/hosts does have the localhost entry.
Yet when a process is invoked within the BPELConsole, the Initiate tab shows icons for Visual Flow, Audit Instance & Debug Instance which use very similiar addresss - which work. Note a very different referenceId:
https://our_host:our_port/BPELConsole/default/displayInstance.jsp?referenceId=7cde75f4b22c157a:4d690c8d:1243a74da38:-7ef0&mode=flow
and this also works:
https://our_host:our_port/BPELConsole/default/displayInstance.jsp?referenceId=7cde75f4b22c157a:4d690c8d:1243a74da38:-7ef0&mode=manage
But when using the Instances tab, the links give 404. So why ?

Answer 1

Hi,
I don't understand this behaviour in detail, by now. Could you please state if this is correct?
1. I call an async bpel process A.
2. The message is put in the delivery queue.
3. My client is free again, not blocking.
4. Process A does not show up in Console by now. (If I would call checkpoint(), it would do).
5. A worker takes the message and instantiates the Process A.
6. Process A instance is running now, calling some sync processes.
7. NO dehydration so far.
8. Process A does not show up in Console by now. The called subprocess (sync) do show up, if they are completed.
9. Loop to 6, until Process A ends and makes callback to client.
10. After sending callback, Process A shows up in Console.
11. Now I can monitor, what HAS happened.
I understand, that you can't commit your process data, until a regular dehydration point is reached.
But consequence: I can't even SEE that there exists a process instance from A, until it worked through all the steps above. I just see a swarm of sub processes without an existing parent.
That's the behaviour, you call "intended"?
Workaround would be to do dehydration after each bpel invoke activity. Do you see a problem in doing this?
Thanks in advance!
Torsten