Its a webservice call through SOAP UI, there is no conversion involved here, the input document to the webservice itself is causing the issue.
As we can see the below snippet of input to the webservice call, when systemId is provided with a singlevalue, IS takes it as a string.
eventhough the referenced wsdl doc is having systemId as stringlist
But when the same systemId is sent with multiple Values, it considers it as a stringList and works fine.
As has been mentioned that is really something that should be corrected upstream.
A possible workaround could be a Java service like below. It needs an input called input of type Object and an output called output of type String List.
Whether or not this is a good idea for your situation I cannot say without the full picture about what is going on.
IDataCursor pipelineCursor = pipeline.getCursor();
try {
Object input = IDataUtil.get( pipelineCursor, "input" );
String[] output = null;
if (input != null) {
if (input instanceof String) {
output = new String[1];
output[0] = (String)input;
} else if (input instanceof String[] ){
output = (String[])input;
} else {
throw new ServiceException("Input must be String or String List");
}
IDataUtil.put( pipelineCursor, "output", output );
}
} finally {
pipelineCursor.destroy();
}
Yes there is. The XML string from the caller is converted to an IS document (a variable structure) at run-time. Those are variables you see in the pipeline in the screen shots you shared.
Consider the XML snippets you shared. How is wM IS to know that systemId is should be treated as a list when there is only one value present? It cannot do so. It must have additional information to know that it is treat a single systemId element as though it is the entry of a 1-item list. As noted in an earlier reply, there are a couple of ways to do that.
If by âupstreamâ you mean earlier in the IS components that are processing the XML, I agree. The processing of the XML string from the caller needs to use documentTypeName or makeArrays. The XML is perfectly acceptable.
Java is absolutely unnecessary in this case.
@tahaseenshaik999 â review the description of pub.xml:xmlNodeToDocument, paying particular attention to the inputs named arrays, makeArrays and documentTypeName.
Please share the components that are being invoked by the caller. There is likely something missing in one of the custom steps or in the provider WSD (if youâre using that).
I ask because the WSDL used to create the IS components is not referenced at run-time. Other elements define the doc structure.
What do you mean by referenced WSDL doc ? Where is it referenced, if not flow steps are being called before this ?
I agree with that in the sense that it is not the regular way to it.
Your comment made me think whether or not my suggestion could be considered bad advice, and if so under what circumstances (or even across the board).
Of course being prejudiced, my current thinking (and I am hereby seeking feedback on that) is the following:
The downsides with my approach are
The pros
makeArrays input and likely similar on the run-time sidemakeArrays which is not location-aware within the overall document structureSo I overall think that the makeArrays etc. approach is certainly what should be aimed for. On the other hand due to time constraints we make compromises all the time. In that light I would not see my workaround as a big issue.
To reiterate: I am not trying to be difficult or defensive, but think this is an interesting case to discuss trade-offs.
Thanks for your feedback.
Not bad advice but perhaps premature. The OP has not shared exactly how the XML is parsed to an IS doc var. The usual thing to do as you note is to set the right inputs to xmlNodeToDocument so that the structure is as expected right away.
If the OP indicates, which seems unlikely, that there is no control possible to get the string list ârightâ in the first place, then the Java code would be a way to go (could do it with FLOW too).
The âsolves the issue right nowâ is true but IMO is short-sighted. As you note, this is not the regular way to do it. As such, the action now is to determine if the regular way can be used, IMO.
Regarding the makeArrays â yes, that is a weak way to do so. For simple docs is fine. I think Iâve used that maybe once in the past many years. The 2 primary ways I use xmlNodeToDocument is with no inputs other than the node (for simple docs where we know there will be no ambiguity for single elements) or with makeArrays set to false and documentTypeName specified.
Making structural changes after the doc is instantiated is not a terrible approach but itâs a last resort sort type of thing.
Not at all! The exchanges are great!
We might disagree on this one being a good one for evaluating trade-offs though â IMO, the use of a documentTypeName is the way to address this. And if the OP shares the details of what the top-level service is doing we can figure out what adjustment needs to be made to properly parse the XML without any âadd-onsâ. 
Its a webservice call and the input to the service is the request reference doc which we send as an SOAP xml from input, so our IS service directly has the doc ref and no conversion (from xml string to IS DOC) is involved here.
below is the input we send from SOAP UI
Input to our webservice at IS is the referenced doc
we can see that the referenced doc, distributionList/systemId is a stringlist.
Can you share the content type that you use to post the SOAP ? And the URL ?
The input and doc type look good. That brings me back to your earlier screen shot â where you show a MAP step that is mapping to distributionList/systemId, not from it.
Where is partnerSystemId coming from? Thatâs the part of interest.
Namespaces can also be a problem. The screen shots donât show the declaration for the tns namespace prefix in SoapUI nor in the doc type. Can you share those and confirm they are the same?
Sorry Reamon, if that has confused you.
Actually the variable partnerSystemId is mapped from the Input distributionList/systemId
Initially i showed the issue at later point of time in the the service after copying the value from input to other serice input - partnerSystemId
but issue is that the input distributionList/systemId is coming as a string during run time when only one systemId is passed
If the input is showing up incorrectly that can only mean that the input is being converted without the document reference. So please check the namespaces tomake sure they are matching
Can you share the details of that? You showed only the case where partnerSystemId is mapped to distributionList/systemId, not from it.
Perhaps, but youâve never showed any evidence of that. Everything youâve shared so far seems to be later in the processing. There was this screen shot showing a string var under distributionList:
But in the context of how this thread has gone, that seemed that was the state of the pipeline after the map to distributionList/partnerSystemId and not a screen shot of the top-level entry service.
Please share the details of the entry service. We see the inputs, which look good. What is the service doing? What the namespace declaration for the tns prefix that is shown in the input?
For the SoapUI payload, please share the complete envelope including namespace declaration. In the screen shot of SoapUI you masked out the namespace prefix of the receive element â not sure why that was considered sensitive. It does not need to be âtnsâ but the associated namespace it references in the SoapUI payload does need to match the namespace defined for your receive service input document.
As @rupinder1 notes, with the information so far, this looks like it may be a namespace mismatch issue â and to be clear, the âtnsâ shown in the input of the service screen shot is not the namespace. That is a prefix for a namespace. The prefix is an abbreviation for the namesapce.
I seem to remember that this behavior (data coming as string when only one value provided) is a behavior from DSPs. I solved it with a âsanitizingâ service that checked if the list was on the pipeline, and if not create it from the single string found.
DSP activity is going to be attributable to browser and form POST. And the configuration in IS for how to handle repeating URL parameters (when they donât repeat.).
Itâs a decent thought but the info from the OP at this point does not indicate DSPs or browsers are involved. Something amiss between the HTTP client and the entry service.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.
