XMLPARSE_NAME:View name mismatch: SCHEDULES != IN_MESSAGE_REQUEST at [2:1]

Hi,

Think you are trying to invoke the bizapi LoadInboxMessage. This error message indicates that the XML you have provided to the bizapi is not the XML expected by the bizpi. You have provided a XML of <SCHEDULES>  but the bizapi expects XML of <IN_MESSAGE_REQUEST>.

Hope this helps.

May be there is a data format mismatch. Verify your data formats for example, if there is a date value then you might have DD/MM/YYYY where it accept MM-DD-YY.

Thank you both very much.

I have focussed so far on the XML elements but not really considered the date formats. I just couldn’t figure out if the error referred to connectivity configuration or the XML data but now I have a couple of things to focus on.

Thanks again.

If we use <SCHEDULES> then error message is:

SCHEDULES != IN_MESSAGE_REQUEST

If we use <IN_MESSAGE_REQUEST> then error message is:

IN_MESSAGE_REQUEST != SCHEDULES_REQUEST

If we use <SCHEDULES_REQUEST> then error message is:

SCHEDULES_REQUEST != IN_MESSAGE_REQUEST

The help system tells us what data elements to use but not what the XML header should look like, so we used an outbound XML as the template for inbound.

How is the setup of the routing address done?

Form the error messages you get it seems like you have two routing addresses and both are in one chain link.

If you are using the STD example routing rule “Example: Incoming Customer Schedule” it needs to be modified. It must have two chain links like in the picture below.

First chain link shall have routing address “Incoming Receive Customer Schedule (ITS)”

Second chain link shall have routing address ”Load Connectivity Inbox”

To get the chain links you shall use the RMB method “Set as Main Address” on the existing routing address “Incoming Receive Customer Schedule (ITS)” and then press save.

Now you can send in the XML on the format which you can find in the interface browser (SCHEDULES).

Thank Tomas.

I had tried that but it still didn’t work. There seems to be an issue where the LoadInboxMessage requires an element that the MESSAGE_RESPONSE file doesn’t include. If I take the MESSAGE_RESPONSE file and edit it, adding the missing element, then use LoadInboxMessage, it loads correctly.

I have therefore implemented a workaround. As we are already converting inbound messages from VDA to EDIFACT, instead of converting to DELSCH, I am converting directly to the MESSAGE_RESPONSE format and loading the messages using just LoadInboxMessage and bypassing ReceiveCustomerSchedule.