Hi Eric,
Please see my comments inline,
So the following data should be logged
(I'll write them down as COLUMN_NAME: value)
req_arrived_at: 24.05.2007 15:01:01,221 (some timestamp)
req_client_id: [EMAIL PROTECTED]
req_service_name: catalog
req_service_version: 1.1
req_opt_parameters: country="de";brand="xyz"
dest_name: catalog_1.1_prerelease
dest_protocol: http
dest_ip: 127.0.0.1
dest_port: 8888
dest_path: /remoting/service/CatalogTestService
res_http_status: 500
res_faultcode: saop:Server
res_faultstring: Some error description
res_time: 10
And now my questions: :-)
- Which of these requirements are covered with the current
implementation and which are not?
Well, all these information can be retrieved within a log mediator
specified as properties but you might need to right a custom log
mediator to collect response time and stuff like that. At the same time
it will be effective to use a custom comprehensive log mediator to
tackle this requirement because there is a considerable amount of data
per record.
- How can we improve the current implementation to meet these
requirements? Where shall one start?
We will need to add the message arrival time as a message context
property so that the custom log mediator can retrieve that information.
(Because we cannot consider the logging time as the message arrival time
on a time critical system). We had a similar requirement and I think it
is worth to add this information on receiving a message to synapse. Also
the response time handling has to be a little tricky if you require to
find the difference between message receiving time and the response
message out time. Apart from these two requirements retrieving the
information that you required is just built in to synapse / ESB.
We have a DBReportMediator which is designed for reporting purposes and
that can be used for the database logs and the asynchronous nature can
be achieved by using a clone mediator to clone the message and give it
for logging while the send mediator sends the message out.
You should start on writing a custom log mediator, which ideally should
be put before the send mediator with a clone in the configuration.
http://wso2.org/library/2898
http://wso2.org/library/2936
- Do we need to have some kind of AsyncLog-Mediator in the incoming AND
the outgoing sequence?
Yes, but as I told earlier asynchronous behavior can be achieved using a
clone mediator before the logging so that we don't have to worry about
that much.
- Is it possible to use only one record for a request/response pair (do
an insert in the incoming sequence and an update in the outgoing
sequence)? How to identify a message uniquely in a cluster environment?
Even in a cluster environment the response should be coming to the same
server which served the request and the correlation between these two
messages are built into synapse, in other words, you can access the
incoming message properties inside the out going (response) message.
- Do you have any other hints on how to solve the requirements?
Lets get started and will provide the necessary information while you
encounter any issues, and we are willing to give our full support on
getting these information to your mediator, also if there are any issue
in retrieving information that you required, you can file a JIRA for
that and we can get them fixed.
Within your custom mediator you may need to check whether the current
message is incoming or outgoing by checking the
messageContext.isResponse() and insert a record if it is an incoming
message and update the record with relevant information if it is out
going message. This way you can avoid having two implementations for the
in and out message logging.
Anything that you want to clarify?
Thanks,
Ruwan
Regards,
Eric
_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
