As everyone knows errors with communication channels can happen anytime even with a very well designed custom adapter. This is one of the reasons why while during developing of a custom adapter you not only need to concentrate on successfull processing of your messages but also on proper error handling and error monitoring. Every adapter can easily report all sort of errors and exceptions into the log service but this is not a tool for an interface developer or administrator to check for interface related issues for at least two reasons:
a) alert framework does not work with errors reported to the log service – and alert framework is the tool you want to use for automated error notifications
b) not a lot of developers nor administrators have access to the NWA/VA, AL11 or any other tool from which you can display trace files
That’s why every adapter can easily send it’s status to the communication channel monitor using the API prepared by SAP. There are two types of statuses that can be monitored using the communication channel monitor:
a) channel status – can use both – pull method – getChannelStatus() and push method – reportChannelStatus() however, both of them are mutually exclusive
b) processing status – used to propagate processing status information with the AAM push method only
The next sections will describe how to use both ways for error monitoring.
Channel status monitoring
Channel status monitoring (pull method) is very often used to validate communication channel information. In adapter metadata we can only specify that some of the fields are mandatory or not. In case we’d like to implement some more file level checks (like e-mail validation, system paths validations, etc.) we can do it using the getChannelStatus() method. The example below retrieves the value of one of the fields from the communication channel (checkValue) and compares it with a predefined string, in case those two match the channel status is changed to error and a information message is reported to the channel monitor.
|
import com.sap.aii.af.service.administration.api.monitoring.ChannelState; import com.sap.aii.af.service.administration.api.monitoring.ChannelStatus; import com.sap.aii.af.service.administration.api.monitoring.ChannelStatusCallback; import com.sap.aii.af.service.administration.api.monitoring.ChannelStatusFactory; ChannelStatus cs = null; ChannelStatusFactory csf = ChannelStatusFactory.getInstance(); String checkValue = channel.getValueAsString(“checkValue”); if (checkValue.equals(“INCORRECTVALUE”)) { cs = csf.createChannelStatus( channel, ChannelState.ERROR, “Check Value: ” + ” is not correct.”); return cs; } |
Processing status
This monitoring mechnism is even more popular as with it you can implement all sorts of monitoring info within your custom adapter and it will be displayed in a row format so you can always check a few statuses back. That’s why you can easily trace the whole error info with it – starting from the first issue and finishing at the last one. There are a few ways to call it but I will just describe two of them.
a) in case you’d like to report any error or info message with the message ID you can use the code below
|
import com.sap.aii.af.service.administration.api.monitoring.MonitoringManager; import com.sap.aii.af.service.administration.api.monitoring.MonitoringManagerFactory; import com.sap.aii.af.service.administration.api.monitoring.ProcessContext; import com.sap.aii.af.service.administration.api.monitoring.ProcessContextFactory; import com.sap.aii.af.service.administration.api.monitoring.ChannelDirection; import com.sap.aii.af.service.administration.api.monitoring.ProcessState; MonitoringManager moni = MonitoringManagerFactory.getInstance().getMonitoringManager(); ProcessContextFactory.ParamSet paras = ProcessContextFactory.getParamSet().message(messg).channel(channel); ProcessContext proc = ProcessContextFactory.getInstance().createProcessContext(paras); moni.reportProcessStatus( this.adapterNamespace, this.adapterType, ChannelDirection.SENDER, ProcessState.OK, “Message OK, procc); |
Example:
b) however if you expect that the error in your process might have prevented the message from being created you can also call this monitor without specifying the message as shown in the code below
|
MonitoringManager moni = MonitoringManagerFactory.getInstance().getMonitoringManager(); ProcessContextFactory.ParamSet paras = ProcessContextFactory.getParamSet().channel(channel); ProcessContext proc = ProcessContextFactory.getInstance().createProcessContext(paras); moni.reportProcessStatus( this.adapterNamespace, this.adapterType, ChannelDirection.SENDER, ProcessState.FATAL, “Process failed”, proc); |
Example:
If you manage to implement the error (and other status info) monitoring correctly – not only developers and administrators will be happy but you can also expect less issues with adapter as usually if the users see the error quickly then can also quickly solve it and it’s not the case if users cannot find the error info easily in the first place.
New NetWeaver Information at SAP.com
Very Helpfull