I added a Log Message task to my Snap-In and can find the output message if I run "ce dlogw EngagementDesigner." Is there a way to see log messages for only my Snap-In and not every other workflow Snap-In? For instance, is there a way I can run something similar to "ce dlogw <mySnap-InName>"?

Thanks!

Andrew,

When you use Log Message task in a workflow, it logs those messages in Engagement Designer log as you have stated. The Log Message task does not log the messages in their own separate log file, even though the deployed WFD is created as a separate snap-in. In other words, that task does not distinguish the workflow snap-ins from Engagement Designer snap-in. This is designed this way to support future enhancements within Engagement Designer.

However, to answer your question, you can define log levels for different snap-ins using the very same command you have mentioned. Just not for workflows - as workflows run under the umbrella of Engagement Designer snap-in.

I hope this helps... Please let me know if otherwise. Thanks!

Thanks. I figured that would be your answer.

I do have a second question, though. I cannot seem to get log messages to appear when I change the log levels. Everything works well when it's Warn and Info, but if I set it to something higher like "Fine," the log messages do not appear in the Putty output. I am going into Logging on SMGR, setting, and committing the higher level. Is there something else I need to do?

I just tested it with a workflow using that task type and I got the log message in FINE level in the Engagement Designer log:

2016-10-24 12:56:31,330 [WebContainer : 0] EngagementDesigner FINE - EngagementDesigner-3.3.0.0.715119 - Prakash: This is a FINE level message!!!

There are two thing that may be going on here:

(1) When you set the log level to anything higher than INFO, there is a lot of logging that goes into the log file and the message you are logging through the task may be buried in those messages...

(2) If you are changing the log level from SMGR, may be, it could take a few minutes for those log level change to take effect. After changing do you see other FINE level log messages in the Engagement Designer log?

Maybe, instead of changing it from SMGR, try changing from the putty session directly using:
ce dlogon EngagementDesigner

This should turn ALL logs on for that snapin. And it takes immediate effect. Please let me know if that works. Thanks!

You are correct. There were so many messages that it scrolled off and was lost. I sent the data to a file and there is was. Thanks again.

One more question. If I run "ce dlogon EngagementDesigner" are the log levels only increased while the command is running? Do I need to do anything afterwards to bring them back down? For instance, do I need to run ce dlogoff?

No, that command actually sets the log level of the snap-in. Once you set it, the log level is set to ALL as you see in the output of that command. To turn it back to INFO level, you do "ce dlogoff EngagementDesigner".

Thank you again.

Is there any option to return log string?
I'm triggering my flow (HTTP) by Post request, how do i return the call status ('shortReason':'answered' ; 'shortReason':'ended')back to the sender?

Shay,

I am not sure I completely understand your question. I will try best to answer, and please let me know if this answers your question:

When you say you are triggering a workflow through HTTP post, I am assuming that you are either posting an event into the Breeze Eventing Framework, or you are calling the Engagement Designer's Create Instance API. And this happens from outside the realm of Breeze / Engagement Designer if my understanding is correct. There are a couple of ways you can get a response back from a kicked off workflow:
(1) Through the Breeze Eventing Framework itself. In Terminate and End event nodes' properties, you can pick up a catalog event. Upon terminating / ending your workflow, this event will get published into the Eventing Framework with the payload you set for the selected schema in your workflow. You can have a listener for that event - a snap-in or a different workflow - which can react to this response.

(2) You can use the REST Service task within the workflow itself to call into any of your own REST services that will "receive" a response back from the kicked off workflow. In this case also, you need to have some sort of a service that can get such such responses and do what you need to react to those responses.

Please let me know if I understood your question right and gave you an useful answer. Thanks!