Starting build 8653, a new mode allows users to run one workflow per execution instance, you can refer to the switch document on the following link Switch to Message Center Archive Workflows
I have deployed a couple of ACC 7.0 18.6 sandboxes on my AWS environment and have found that with each one of them the new message center archiving workflow fails at the end of the the work, spefically the "End" activity, it also fails on new upgraded environments where this new archiving workflow has been made accessible.
06/02/2019 10:30:36 end SCR-160012 JavaScript: error while evaluating script 'mcSynch_local/end'.
06/02/2019 10:30:36 end JST-310000 Error while compiling script 'mcSynch_local/end' line 2: vars.dateCurrentStart.getTime is not a function.
Has anyone come across this issue as well, if so how did you fix it? I have spent some time fixing the OOTB workflow and introduced a bit of custom code to get around the problem.
Original code
setOption('MC_LastQuarantinesSynch_' + vars.cellId, new Date(vars.dateCurrentStart.getTime()));
var sg = new StringGroup("nms:messageCenter");
logInfo(sg.synchDone());
instance.vars.running = false;
My Custom Code
//start fix David Garcia
vars.dateCurrentStart = "";
var optionName = "MC_LastQuarantinesSynch_" + vars.cellId;
var option = getOption(optionName, false);
if( option ) {
vars.dateCurrentStart = option;
//debug logInfo("option "+option);
} else {
vars.dateCurrentStart = vars.NOW;
}
//end
setOption('MC_LastQuarantinesSynch_' + vars.cellId, new Date(vars.dateCurrentStart.getTime()));
var sg = new StringGroup("nms:messageCenter");
logInfo(sg.synchDone());
instance.vars.running = false;
The issue is that the vars.dateCurrentStart variable which needs defining.
Has anyone come across the same issue? is this something Adobe needs looking into? can you guys replicate it.
Solved! Go to Solution.
I see Local is an exception there as everything else should be a number.
Can you check what is the value for option "NmsExecutionInstanceId", "MC_LastEventsRtSynch_%" and "MC_LastEventsBatchSynch_%"?
if any of these values are missing then you have to fix it.
in your case, "NmsExecutionInstanceId" should be set to 1
"MC_LastEventsRtSynch_%" and "MC_LastEventsBatchSynch_%" should be set to a valid date time. something in past.
David,
I have used this workflow for a couple of clients but never faced this problem.
the way you have explained it here it seems you are missing some correct options in your configurations.
step 1: Validate the workflow properties, check do you have a correct extAccountId?
step 2: check if you have all required MC_% type option highlighted below.
step 3: remove your custom code and check the advanced tab for js code
the similar code should be available for all "Archiving finished?" jstest activities.
Regards,
Amit
Thanks Amit,
If you have an instance which is both control and execution and deploy the new archiving workflow from within the deployment wizard as explained in the installation document it will create a mcSync_local archiving workflow with the extAccountId of local
However, if you create the archiving workflow from withing the external account execution instance it will create the archiving workflow and append the extAccountId by default.
I tested both archiving workflow and only the mcSync_local fails.
So what determines a instance that is both control and execution? is it a single instance running all services (Standalone Deployment) with a message centre deployed locally? or even a Standard deployment would have the control and execution for message centre.
Views
Replies
Total Likes
I see Local is an exception there as everything else should be a number.
Can you check what is the value for option "NmsExecutionInstanceId", "MC_LastEventsRtSynch_%" and "MC_LastEventsBatchSynch_%"?
if any of these values are missing then you have to fix it.
in your case, "NmsExecutionInstanceId" should be set to 1
"MC_LastEventsRtSynch_%" and "MC_LastEventsBatchSynch_%" should be set to a valid date time. something in past.
Views
Likes
Replies
Views
Likes
Replies