TN processing rule - responds with

, ,
1

We are submitting a document that is kicking off a processing rule and running correctly. Our issue is we are expecting the processing sevice to return back the value within the kicked off service to be returned from the tn.receive. The value is not being returned. We have put debug log’s, tn.log’s, trace pipelines and the value is there in the kicked off service but once the service has completed the tn.receive the value is no longer there. Is there something within the processing rule or the package that we need to set up to get the value returned?

2

Can you describe your configuration a little more?

Is the caller invoking wm.tn:receive directly, or is it calling a wrapper service which calls wm.tn:receive? If using a wrapper service, I assume you’re expecting the pipeline to contain the variables your service added, which leads to…

How is the processing rule configured? Are both Execute a Service and Respond With a Message selected? Or just one them? Is the Execute a Service configured to run sync, async or as a service execution task?

What sort of data do you want to return to the caller? HTML? XML? Just a value?

3

Rob,
The configuration is like this -
I have a wrapper service which makes the call to ‘wm.tn:receive’. I assume the reponse value to be available in the pipeline when the control returns to the step next in the wrapper service, but i do not see that variable in the pipeline.

The processing rule which gets triggered is set to ‘Execute a service’ and ‘Respond with’ a certain variable from the pipeline.
The Executed service is set to run ‘synchronously’.
The data that i am trying to get back is an EDI string. The content type for it is set as ‘text/plain’. But i tried returning a static string, even that did not seem to work.

Please let me know in case you need any more details.

Thanks
Shantanu

4

Remove the “Respond with…” from the actions. That is used to return an HTTP/FTP response (the response is not placed in the pipeline). Since you are invoking receive within your service, you don’t need to do that. Make sure your service invoked by the rule isn’t dropping variables or doing a clearPipeline and you should see the vars.

5

Rob,
This is the structure of my wrapper service –

-Start
–TRY
—GetData
—wm.tn:receive
—tracepipeline
—debuglog
–CATCH
—getlasterror

This is the structure of the service getting called from the processing rule –
-Start
–TRY
—GetDatafrom bizdoc
—do something
—put the output in the pipeline
—tracepipeline
—debuglog
–CATCH
—getlasterror

I removed the ‘respond with’ feature in the processing rule. Still i don’t see the variable getting passed to the wrapped service pipeline.
I see the variable when i do a tracepipeline on the called service, and nothing is dropped from the pipeline.
But the tracepipeline in the wrapper service does not have that variable.
Rather none of the values from the called service are in the wrapper service pipeline.

Thanks
Shantanu

6

Is there some server setting that needs to be done?

7

What is the name of the variable that you are trying to pass back in the pipeline? Take a look at your settings for tn.receive.clearKeys and tn.receive.clearTNObjects. Perhaps this is the issue (but I’m not hopeful).

8

the varilable is named - ‘responseEDIstring’.
is there certain names that we can return back?
by default it returns back ‘$responseBytes’, i tried converting those bytes to string, even that does not have the data i am expecting.

9

The properties I mentioned control what variables receive will drop from the pipeline, if those properties are configured to drop anything. The default settings are to drop nothing.

Where is $responseBytes coming from? That would seem to indicate the rule is still doing something. Is there a setResponseBytes (or something like that) in your bizdoc processing service?

On a side note, is your process doing this:

  1. Receive EDI from partner (say an 850).
  2. Submit to TN.
  3. Return an EDI response document (say an 855).

If so, I’d strongly suggest that you do not do this synchronously–in other words, don’t send the 855 (or 997 or any other doc) back in the same session as the 850 processing.

What you’ll want to consider is in your bizdoc processing service is to submit the resulting document to TN too. Then you can use all the rules, tracking, etc. to manage those response docs. You’ll need to be diligent about keeping the pipeline clean on the second receive call but it will work just fine.

10

Rob,
Even after setting the parameters, it did seem to pass the variable back to the wrapper service.
My service is doing what you explained. And on both occasaions i am routing it thru TN, but the processing rules do not trigger any service.

11

Try this:

  1. Configure the processing rule as Synchronus execution
  2. No need for respond with
  3. in tn.receive output put “responseEDIstring” and Map that to a variable “responseEDIstring”
  4. In above step you will not have “responseEDIstring” in tn.receive so u need to hardcode this mapping
  5. Run the service n see if it is working
12

If the processing rule that runs your service is not getting selected for your document, then it’s no wonder that the vars you’re looking for don’t show up. Fix that and your pipeline variables should show up.

Or did I misunderstand “…but the processing rules do not trigger any service?”

13

Rob,
I think the statement “…but the processing rules do not trigger any service?” was misleading.
I meant to say the processing rule that i have created gets selected, but the processing rule does not have any “action items” selected. It is just a dummy processing rule so that the document does not trigger the “Default rule”.

Thanks
Shantanu

14

Let me make sure I understand your whole process:

  1. A service (e.g. “wrapperService”) is invoked by some HTTP client.
  2. It invokes wm.tn:receive.
  3. In processing the document, TN selects a rule.
  4. This rule is currently configured to do nothing.
  5. Control returns to “wrapperService.”
  6. You want “wrapperService” to have access to pipeline data created by “serviceX”.

To get this to work. the processing rule needs to invoke “serviceX” synchronously. The rule doesn’t need “Respond with…” set but it must invoke the service you want to use.