Custom data in processing rule

Hello ,
sorry for asking repeated queries. I have searched the whole forum about my issue but no luck… :frowning:

Query is related to have pipeline data in processing rule service. below are the things there in my code.

  1. Sending an EDI standard document(Header document (requestId,Sender and receiver details for updating things in DB) and EDI Segment details document) To TN by tn:receive service.
  2. Processing rule service is invoked but i am very much interested in Header document ((requestId,Sender and receiver details for updating things in DB)). ie I want Header document to come along with BIZDOC. FYI, Explicitly I have placed Header as input in processing rule service.


  1. I have preserved EDIDATA and Header document in the service which sends EDIDATA to TN
  2. Execution mode is synchronous in processing rule service.
  3. As everybody knows, Header document will not there in EDI standard but i need to track it processing rule service to update the DB status and to catch error if any failure.

Please provide your valuable suggestion on this. Really thanks in advance.

In the processing Invoked TN service inputs did you set/see bizdoc,sender(ProfileSummary),receiver(profileSummary) references and so that can be used for your extracting sender/receiver details and updating in DB usage?


First thing in the processing Invoked TN service inputs did you set/see bizdoc,sender(ProfileSummary),receiver(profileSummary) references and so that can be used for your extracting sender/receiver details and updating in DB usage?

Is that what you are expecting in the pipeline?


What header document are you preserving and requestID what is that you are talking any attribute or identifer in the TN transaction?

Hello rmg,
Thanks for your quick reply. I have preserved "custom document " in wrapper service which sends an EDI data to TN since below fields are required in processing rule service to update the DB status for each transaction.

  1. requestID(unique Id for each transaction. ie its same like UUID). you may call it as transactionId too…
  2. SenderID

fyi, requestId is nowhere related to TN transaction. Purpose of requestId are:
1.requestId is for tracking each transaction in database.
2. requestId is the primary key in database and its maintains the transaction details in DB.


  1. Wrapper service sends an edi data to TN
    i) consider we have 855 edi document and we are sending the same to TN and doc structure is

    ii) edidata has formed with all Segments (without header details since header document is for internal purpose and not to be sent to partner)
    iii) preservation of doument/string has done to Header document and edidata respectively. The reason for preserved header document is to carry the requestId in processing rule service to update the Status of transaction.
    iii) used tn:receive service to send an edidata to tn

  2. Processing rule service
    i) bizdoc is coming with all required documents and i can manipulate the edidata.
    ii) used ediint:send service to send an edi data to defined partner for AS2 connection.
    iii) herewhere i required requestId (exists under preserved header document) to track status of partner delivery details in database.

    As per my understanding, preserved documents/string should be there as a pipeline data in processing rule service when the execution mode is synchronous.

will the execution mode change to Async when AS2 connection is involved?

Hope I am clear enough to provide required information. Please suggest me on getting a custom document in processing rule service when the connection is AS2.

As far the requestID you are looking for then use the “InternalId” from the TN as the transaction identifier if that works for you?

But why do you want to store each transaction in a seperate table when TN db does it for you and you can always query the TN db right for the doc status or userstatus itself?


Hello rmg,

The requestId that we are using in our code is nothing but an "activitationID "(flow is outgoing flow ie SAP ->TN). We want to use the same requestId throughout the flow to track the business transaction.

we are using another DB for tracking business details and herewhere requestId is required . we are not using internalID.

Is there any chance to pass requestId(alone) to unused field to TN ? so that i can get the same requestId in processing rule service.

FYI, i have tried to set requestId as one of the attribute in TN via built-in service before submitting a data to TN. But built-in service required bizdoc :frowning:

Please suggest me how to get requestdId in processing rule service.

Yes create a custom attribute (correlationID or some thing) and assign it to the documentType that you submit to TN and update the attribute during run time for the bizdocid it returns for your correlation:

Is this some thing you are looking for?


Hello Rmg,
you have suggested to create custom attribute and assign the same to documentype. I have a question on this which are as below.

  1. can we create custom attribute to EDI standard documenttype?
  2. If yes for point 1, how to set attribute without bizdoc since service expect bizdoc as one of the input.

Please guide me here… sorry if am troubling you more on this.

Not for EDI standard document types edits…

ofcourse bizdoc/id is required to set/update attribs values:

But for updating attribute use these reference in general:

doc:view (map InternalID from the bizdoc if pipeline has it or use tn:query (createDocumentQuery and documentQuery services to get bizdoc info per the input criteria)


Hello rmg,
I am handling with EDI data so there is no point of adding custom attributes. I planned to use system attribute "conversationId " to track my requestId but problem is “there is no formation of bizdoc before submitting a EDI message to TN”.

you have proposed an idea to use “Tn: query” to form the bizdoc and then to set the attributes before tn:receive service.

As per your suggestion, below are my doubts:

  1. wrapper service which sends an edi data will be having 2 bizdoc at the end of the service ie, 1 will be formed by tn:query to set attributes and other one will be formed by tn:receive. recent one will be there in pipeline and which will go to TN. so nowhere requestId will be tracked.
  2. tn:query service will fetch records when the transaction is already there in TN(based on input that we are passing). Consider a new message which about to send to TN. In this case, Tn:query will not provide records and no bizdoc will be formed to track my requestId.

Please correct me if am wrong anywhere here…

Yes correct you have no way of bizdoc info unless submitted to TN and later retrieval…The only option you have is look in the PSUtilities or use some custom logic to create a unique identifier for your outbound transactions…

You have to really depend on after submitted to TN only not before in your case it sounds: