Processing Rule : Define Action - Execute Service

, ,
1

Hi.

i got an SAP Idoc and transfer it to TN.

Processing Rule is found. Now i want to call an IS service which transforms the received document
and store it with a special filename on a ftp server.

But how to pass the TN document content to the service ? Is there a special signature neccessary ?

Thanks.
Sebastian

2

You should use the bizdoc comes in the pipeline and the signature is BizDocEnvelope document reference…Do you see this bizdoc var in the pipeline of the TN processing action service?

Then for extracting the content use the bizdoc/content (bytes) and do a bytesToString map output string to the downstream FTP steps like PUT for the file content transfer.

HTH,
RMG

3

Yes, there is a special signature. A normal TN bizdoc processing service should use the service specification WmTN/wm.tn.rec:ProcessingService. If you want to execute your service as a service execution task, then you should use the service specification WmTN/wm.tn.rec:ReliableProcessingService instead.

Refer to Chapter 20 Service Specifications in the Trading Networks Built-In Services Reference for what each of the inputs and outputs actually mean. Also, you should read Chapter 5 Trading Networks Document Processing in the Trading Networks Concepts Guide - it has a section about the processing rule actions and what happens when you execute a service. It also explains the difference between synchronous, asynchronous, and service execution tasks.

When you use the above service specifications, your service will accept the following inputs:

  • bizdoc - the actual Trading Networks document which is being processed, as a document reference to WmTN/wm.tn.rec:BizDocEnvelope
  • sender - the Trading Networks sender profile, as a document reference to WmTN/wm.tn.rec:ProfileSummary
  • receiver - the Trading Networks receiver profile, as a document reference to WmTN/wm.tn.rec:ProfileSummary

If you are looking to work with the raw bizdoc content directly (ie. as a java.io.InputStream, byte array, or string), then you can extract the content from the bizdoc in a number of different ways:

  • Use the bizdoc/Content value directly - this is a byte array, so if you wanted to work with the content as a string, then you can convert the byte array to a string using WmPublic/pub.string:bytesToString. Note that this approach will not work with large documents, as the bizdoc/Content byte array won’t exist (large documents use java.io.InputStreams instead - read about large documents in Chapter 5 of the Trading Networks Concepts Guide).
  • Use WmTN/wm.tn.doc:getContentPart - you need to know the name of the content part you want (usually xmldata for XML content, and ffdata for Flat File content); this service returns the content part including a byte array for the content contentPart/Bytes, but only for small documents; you can’t use this service for large documents easily.
  • Use WmTN/wm.tn.doc:getContentPartData - again you need to know the name of the content part you want; this service will return the content as either a byte array or java.io.InputStream, which you can then process as you see fit (convert to string - although this wouldn’t be recommended for large documents unless you have lots and lots of RAM assigned to the Java heap).
  • Use WmTN/wm.tn.doc:getDeliveryContent - returns the content for the default content part as either a byte array (for small documents) or a java.io.InputStream (for large documents).

If you are looking to parse the bizdoc content into an IData document, so that you can map it or use some values within it for your processing, then you can do the following:

  • If the document you are processing is XML, you can use WmTN/wm.tn.doc.xml:bizdocToRecord to parse the XML into an IData document. Note that this service doesn’t work for large documents.
  • If the document is a flat file, then you have to extract the content from the bizdoc using one of the above approaches, and then pass the content to WmFlatFile/pub.flatFile:convertToValues.

As you can see, dealing with bizdocs isn’t particularly straightforward, and you have to do different things depending on whether the document is XML or a flat file, and whether it’s small or large. Annoyed with how complicated all the above is, I’ve created a much simpler way of dealing with bizdoc content in a processing service with my TundraTN package ([url]https://github.com/Permafrost/TundraTN[/url]).

If you want to work with the raw bizdoc content directly, you can use the service TundraTN/tundra.tn.document.content:get, which always returns a java.io.InputStream object, therefore is consistent and always works regardless of whether the document is large or small. The part name is optional, and if not specified the default content part for the document is returned (xmldata for XML; ffdata for flat files).

If you want to parse the bizdoc content so you can work with an IData document, then you can use the service TundraTN/tundra.tn.document:parse. It works for both XML and flat files and both large and small documents. The only caveat is that you need to specify the XML document type and schema, or the Flat File parsing schema, on the Options tab of the Document Type in TN.

An even better way of working with bizdocs is to use one of the following TundraTN meta processing services, which you can call direct from a TN processing rule:

  • tundra.tn:deliver - delivers the raw bizdoc content to a file:// or http:// URL of your choice (I plan on supporting more URL schemes in the future, such as mailto: and sftp://)
  • tundra.tn:derive - makes copies of the bizdoc with an updated sender and/or receiver
  • tundra.tn:process - parses the bizdoc content, and then calls the specified $service to process the parsed content. As tundra.tn:process provides logging, content parsing, error handling, and document status updates, the $service processing service does not need to include any of this common boilerplate code.
  • tundra.tn:translate - parses the bizdoc content, calls the specified $service to translate the content to a different format, then converts the translated content back to a string and routes it back to TN as a new bizdoc.