Skip to main content

                                         Complex Element Type in Custom MPM 

CASE HISTORY: Use of User defined Datatype in Custom MPM Using COMPLEX Element Type. 

Need to use user defined Datatype (as parameter datatype or return type) in Custom MPM using Complex Element Type, so as to represent similar set of data or list of data as response. We created a user defined Model Object to include objects of user-defined datatype. We defined the same in perform definition using Element Type as Complex. When we are calling the MPM from XML Poster, we are getting the response as “Unsupported Datatype”.  

Please find below screen shot of a demo project with same scenario.

User defined Model Object:  

 

 

 

Passing the user defined Model object as parameter to a method and returning the same: 

 

 

 

Response from the XML Poster:  Unsupported Data Type.

 

 

 

Hi @Drevlin ,

 

Could you please explain the actual requirement with more details here? And how did you actually pass the parameters and  defined the Return Type? Can you share a screenshot of your perform message in FSM?

 actual requirement : we are building custom MPM which will be called from OdataAPI by Foreign System as Integration outbound call.

Foreign system will send complex type xml or json.

The custom MPM should accept complex type object (User defined )   data type  as a parameter. But is not supported .

The screen shot is already updated.

Hi,

I had a similar case some months ago and when I consulted the RnD, they had mentioned that it is not supported in the way customer is implementing it. FSM only support custom entity classes (data tables) and baseline server objects as the data type for a complex perform parameter. RnD suggested to make this work by defining the data type as "xml" and then add some code within the MPM C# class to parse the XML to get the data needed from the child XML nodes.
Hope you got the answer to your question.

 

Thanks & Best regards,

Hushan Hasarel

@Jon Reid @Aaron.Sleight 

The workaround of using a standard HTTP connector for MPM’s the customer running but it comes at a cost of an additional connector.  What is the status of the internal JIRA project to follow-up with Boomi?

The workaround was given to the customer about a year and ½ ago and the case was closed as Product Support - Third Party Product Fault. The customer has since reached out and is asking if Is this on the docket for inclusion ? or in other words, do you have a timeline because they have a library of integrations that depend on it and this is urgent for the customer.

Terms & ConditionsCookie settings