Graphical Mapping - Capture a specific mapping error and send an Alert for only that error

[Former Member]

We would like to capture only specific mapping errors (like a required field that wasn't set) which will error in the mapping with "Target XSD requires a value for this element"... Then create an alert to the business via email so email the business only for a specific error.

Our thought was use SALERT_CREATE RFC to send an alert for a specific mapping error however for graphical mapping we are sure of all the options to catch this specific error.  Looking for ideas.

We could use a UDF at each field and verify if a value was passed and if not send it through the UDF to create an alert.  However when there are a lot of fields this isn't practical from a mapping standpoint but would work.

If we were using Java mapping it would be easy to catch the exception but from the graphical mapping side what would be our options.  We are familiar with a few but would like to see what others think on this one.

Thanks!

[baskar_gopalakrishnan2 · Accepted solution]

IMO, using java mapping you can capture and customize error message for every fields.  In case of graphical mapping, you might not achieve the same. My suggestion is you can use xml schema validation option for your inbound or outbound messages and the errors can be alerted via alert framework.

You can search SCN for schema validation.

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/d06dff94-9913-2b10-6f82-9717d9f83...

[Former Member · Accepted solution]

Baskar - Thanks for the reply!  I agree with you that the schema validation for this issue will work for this case.

Currently they have alerts setup to email any errors but they are only getting the messageID and a generic error when it fails in the mapping.  They want to send the alert directly to the business instead with specific detail that they will need to know exactly what the problem is to fix the issue.

If we did schema validation we could separate those errors from other mapping errors that could occur with the standard alerts.  The problem will be using standard alerts sending the detailed information needed to the business.  I will setup a test for this situation and see what gets generated for the error message and see if it will be enough for the business.  My concern is it won't but I'll test and verify.

They are currently running PI 7.1 so would be better if PI 7.3 to avoid putting the schema file in the directory but not an issue.

I'll post back to the group what comes of this test. 

Thanks for your reply.

Steve

[Former Member · Accepted solution]

Baskar,

See my reply below.  We are trying schema validation and the catch is its an IDOC to file scenario so we are trying to validate the IDOC in PI.  See note below in explanation.  thanks!

[Former Member]

Ok we went the route of schema validation.  The twist to what we are doing is we have an IDOC to File scenario so we want to validate the incoming message.  Long story but the IDOC fields are set to 0..1 but the receiver file is set to 1..1 which is valid. 

They don't want to change the IDOC fields to 1..1 because the data comes from a 3rd party and its hooked into ECC and the IDOC is getting generated.  Because of the process they have in place they want to instead catch the error in PI versus in ECC on creation of the IDOC.

So I created the sender agreement for the IDOC and set the validation to "Validation by Integration Engine".  We put the IDOC schema file in the directory "

D:\usr\sap\PID\SYS\global\xi\runtime_server\validation\schema\e5a519a0766111dca2e8e95d0a115642\ZPROD_ORDER.ZPROD_ORDER01\".

However when we run it we are getting an error in moni of an invalid directory path which has special characters in it so we know obviously its wrong.  It would appear you probably can't do schema validation on outbound IDOCs.  I'm guessing we need to use a service interface. 

Here is the error message:

<SAP:Category>XIServer</SAP:Category>

<SAP:Code area="XML_VALIDATION_INB">CX_XMS_SYSERR_VALIDATION</SAP:Code>

<SAP:P1>Schema ZPROD_ORDER01.xsd not found in D:\usr\sap\PID\SYS\global\xi\runtime_server\validation\schema\00000000000000000000000000000000\ 奠 va Ü¢èé~  VB\ZPROD_ORDER.ZPROD_ORDER01\ZPROD_ORDER01.xsd (D:\usr\sap\PID\SYS\global\xi\runtime_server\validation\schema)</SAP:P1>

So all the 0's in the directory plus the invalid characters as well shouldn't be occuring.  My thought is you can't do IDOC validation when outbound?  Looking for anyone's thoughts on this.

thanks,

Steve D

[Former Member]

Hi Steve,

how about the IDoc Validation? It works?

Regards

Rene

[Former Member]

Hi Steve,

Greetings!

Did your Java mapping worked for you as intended?

We are also having a similar task at hand where in we are trying to raise custom error messages for Alert Framework during conditional validations. With PI 7.3 Java stack and Alert Framework now sitting over java I guess using the Java would be the only solution left with us now.

Please share all your findings and challenges faced during implementation of your solution. I found the below blog helpful but still not sure if the audit log information will be forwarded to Alerts.

http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/07/15/write-mapping-message-to-rwb-audi...

Regards,

Rahul

[Former Member]

Hi Steve,

I think Baskar's suggestion (i.e. XSD / XML validation in the Adapter engine) is probably the best solution. When you are designing the sender interface (data / message types) you stipulate mandatory fields and even enumeration (i.e. permitted values). You won't need a UDF for each mandatory field, just re-use what you have already developed (data / message types).

You then setup the validation and if the incoming message doesn't adhere to any of your requirements, it's stopped before it reaches the mapping and an alert is triggered. It just saves time, looks easier on the eye & saves processing on the PI server. So anything that you can stop earlier in the process chain is always better, I think anyway...

Regards, Trevor

[Former Member]

Trevor,

I like that solution as well but only concern will be can we send an email to the business with enough detail for them to fix the problem which is the main goal.  I'm going to setup a test case for this to verify.

Thanks for the reply and I'll post back how this works.

Steve

[udo_martens]

Hi,

you can use Michal's idea XI/PI: Throwing Generic Exceptions from any type of Mapping A udf just on the a certain field / situation would solve that..

Regards,

Udo

[Former Member]

Udo,

This is what some of the technical people here feel is needed but the thought of having to put the UDF in the mapping for each field that is required is a concern.

However it will give us the option to put in the detail we need to send back to the business so they can resolve the issue.  So this for sure will give us what we need and allows us to send key fields(sender info, receiver info, etc.).

I do like the schema validation route since its much cleaner but I need to do a test to see if we can send enough information back to the business when it errors.

Thanks for your reply!

Steve