Hi,
Is there any way to change the Processing Status of a document in TN.I know we can change the User Status and the System Status by invoking wm.tn.doc:changestatus.
ramesh.
Only using the above service wm.tn.doc:changestatus we can do change processingtatus of the persisted document in TN.
I believe there is no other custom way that can change directly in TN.
HTH,
RMG
Just in case there’s any confusion, the ‘system’ status is the same as the ‘processing’ status and this service can be used to update it. Thanks,
Tim
RMG,
wM doesn’t recommend changing Processing Status. so we thought we will change the user status.But in the TN Console the user status doesn’t change even after i invoke changeStatus.i have to create one more processing rule with the new user status.then i have to reroute the doc to TN and the new processing rule picks up this doc.
my requirement is whenever we change the user status,it should show up in the Transaction Analysis screen.
is there any way to do it without creating a new processing rule and rerouting the doc to TN.
ramesh.
RMG/Tim,
what i observed from the Activity Log is,the user status is being changed to new status,but again it is changing the status back to the user status set in the processing rule.this happens even after i invoke EXIT step right after invoking changeStatus.
ramesh.
Ramesh,
I was able to set the user status by not checking the ‘change user status’ action in the processing rule and then branching in my service to set the user status conditionally by calling the changeStatus service. I think if you check the box TN always sets the status after you invoke the service. HTH,
Tim
Ramesh,
Tim’s solution is the right approach,even we dont use the Processingrule’s ChangeUserStatus option we keep in the flow depends on the processing status values using changeStatus service.Well it wont harm even we change systemStatus,i understand WM doesnt recommend but some times the requirement uses custom statuses.
HTH,
RMG
RMG/Tim,
Requirement is there should be Processing Rule’s Change User Status set and as well as change the user status from the flow service on specific condition.so, if the condition is not met,user status in Transaction Analysis shows the processing rule’s change user status else if the condition is met it should show the user status from the call to the changeStatus.
Let me know if this is possible.
Thanks,
ramesh.
yes i believe this is possible based on the conditions when you use both Processingrule vs changeStatus service…may be you are missing some condition in tbe branch,can you elaborate your flow.
HTH,
RMG
RMG,
The processing rule’s status is set.and when processing the X12 Group,when a specific condition is met,i invoke changeStatus and set the status to let’s say “Error” and exit out of the flow.But when i check the Activity log,i see the status is changed to “Error” and the last entry in the Activity log shows that status is reverting back to the status set in the processing rule.
As Tim said,this works if we dont set any status in the processing rule.
ramesh.
Flow.doc (32.8 k)
I think RMG is right. I just did the following: set the processing rule to change the user status to ‘TEST’ and put a branch in my flow service to change user status to ‘TEST1’ based on a condition. If the condition is not met, the service does nothing. The behavior I saw was that when the condition was met, the user status was set to ‘TEST1’ and did not change. Otherwise it was set to ‘TEST’ by the processing rule. So it seems like it should be possible to do what you need.
Tim
I wonder if this could just be a latency problem. I noticed the behavior Ramesh describes, but when I went back to the document later the status was set correctly to the value specified in the service. This was especially noticable when I included an EXIT step, as Ramesh has, following the changeStatus call.
Tim
Tim,
I removed the EXIT call and even then the status is set back to Processing rule status.Just check in the Activity log.first status changed indicates that status is set to Error and the next status changed indicates that it is set back to the processing rule’s status.
ramesh
TNActLog.doc (30.2 k)
May I suggest that the user status be set in one place or the other? Having the status set sometimes in the rule and sometimes in the service is a maintenance headache–and apparently a development headache too 
Pick one or the other approach and always do it that way. I would recommend always setting the user status within the services, never in the rules.
Rob,
I was wondering whether it was doable or not.i thought i was going wrong somewhere as Tim was getting the correct output in Transaction Analysis.
ramesh.
Fellows,
AFAIK, TN will update the status after returning from IS called service. This might be the reason of the ‘latency’ sensation.
I had a requirement to control the user status and it just worked properly when not checking the ChangeUserStatus option.
HTH,
Maldonado
Try setting the service to be invoked asynchronously in the rule.
Tim
Tim,
when i switch to asynchronous and the condition is met in the flow service, it’s working properly.but the problem is, when the condition is not met,it’s giving undesirable results.just curious to know what difference does it make when we change from synchronous to asynchronous.
ramesh.
With synchronous processing TN waits for the service to complete before it finishes the other processing actions. With asynchronous processing TN executes all processing actions immediately. It seems odd that you’re getting the undesirable results when the conditions are not met, since in that case only the processing rule is changing the status and not both the rule and the service.
It would certainly be cleaner to do as Rob and RMG have suggested and handle all status changes in the services. Is there any chance of getting the specification changed, based on the fact that TN is simply designed to function this way?
If not, I can’t think of any easy or elegant way to accomplish what you need. For example, you could have your service execute as a task and not proceed with normal processing until the status has been set by the rule. I would think that whoever provided the specification would prefer changing it to trying to implement something like this. HTH,
Tim
Setting a rule to invoke a service asynchronously will cause a thread to be created to run the service. The main thread that is processing the document (receive, recognize, persist, etc.) selects the rule and will spawn the thread, then set the status as indicated in the rule and return to the calling entry service. The invoked service that is running in another thread will later change that status.
Be aware that making an invoke async can cause your system to be overrun depending on your document processing. For example, if you’re processing an EDI doc with lots and lots of groups or lots and lots of transaction sets, you can get lots and lots of threads. Perhaps enough to stress your server to failure.
What are the “undesirable results” you speak of?