Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
I have been really irritated at line segments in IDOCS. The build functions have a hard time to make sure it is selecting the right values. They can have a structure as bellow. I have removed values that I’m not using.

This allows for a lot of missing values that have to be tested for. This is the last mapping that I got to create. And it was failing because an element was missing the TDLine. So I knew that I had to find a much better solution to the following mapping. This mapping also caused problems on some data.

I may  have been able to fix it with some standard functions but it will probably end up being too big an issue.

So I wanted to create a more reliable and faster way to make it this type of lines. In my design effort I stumbled of the return as XML that gives the node with child notes as a value.

If this XML option did not exist I would have required 4 input the key input 2 times and the target value 2 times at different contexts. It would have been messy to work with but possible.

The return as XML is something that I not have been using. I have just on one occasion a few weeks ago. I could not see a good benefit of using it.  Here it makes a lot of sense, because it is return the full E1TXTH9 in one element. Then it is just to create a parser for it.

The configuration is simple.

  • Key is the place where it should look for a value

  • Allowed values is a comma separated list of allowed keys. If any of the values are found the current node and it parent will be selected.

  • Fields to return. Name of the field to be returned.

All positive results will be added to a text string that is returned for the context. So there will only be one output for a queue. In the example above ZSSI does not exist in the input data, so it will not be returned.

The function can also be used on partners segments to find values. Both on header but more importantly on line items where it can be a lot more difficult to find the values.

The code is here

@LibraryMethod(title="selectXMLValue", description="select values from a XML element", category="GF_EDIHELPERS", type=ExecutionType.ALL_VALUES_OF_CONTEXT)
public void selectXMLValue (
@Argument(title="node in return as XML") String[] xmllist,
@Parameter(title="field where the key is located") String keyfield,
@Parameter(title="comma seperated list of allowed values") String keyvaluelist,
@Parameter(title="if the key is found which field values should be returned.") String resultField,
ResultList result,
Container container) throws StreamTransformationException{
StringBuffer sb = new StringBuffer();
for (String xml : xmllist) {
String[] keyvalues = keyvaluelist.split(",");
DocumentBuilder docBuilder = DocumentBuilderFactory.newInstance()
Document document = docBuilder.parse(new ByteArrayInputStream(xml.getBytes("UTF-8")));
NodeList tagslist = document.getElementsByTagName(keyfield);
for(int i = 0; i< tagslist.getLength();i++) {
Node node = tagslist.item(i);
String nodename = node.getFirstChild().getNodeValue();
for (String keyvalue : keyvalues) {
//add the content of the result field to the output
//look from the parrent node
Element parrentNode = (Element)node.getParentNode();
NodeList resultList = parrentNode.getElementsByTagName(resultField);
for(int j = 0; j< resultList.getLength();j++) {
Node resultnode = resultList.item(j);
result.addValue( sb.toString());
}catch(Exception e){
throw new StreamTransformationException("Unable to parse xml", e);

Update: 20140508: with xml.getBytes("UTF-8") to avoid


If you want you can also download the Figaf Tools package for free at
Labels in this area