Finding next available appointment date when creating an appointment in CRM Script
Hello friends!
I've been messing with the Netserver Appointment Agent:
https://docs.superoffice.com/automation/crmscript/reference/CRMScript.NetServer.NSAppointmentAgent.html
But I can't get it to do what I want to automate.
I'm trying to do this:
In the image, I get a selection of the next available time slots that fit the appointment without conflicts - so the functionality is there.
But how is it made available to either the REST API or CRM Script ?
I'd rather not implement a similar function myself, as I'm concerned with how much performance it will eat from the system.
I hope you can help.
All Replies (5)
Hi,
This is based on the 'NextAvailableTime' MDO provider, sample using CRMScript:
#setLanguageLevel 3;
// MDO provider: NextAvailableTime
// Format additional info [<DateTime start appointment>][<DateTime end appointment>]|<is all day event? 0/1>|<associate id>
// [DT:09/08/2022 11:30:00.0000000]|[DT:09/08/2022 11:45:00.0000000]|0|1993
DateTime start = DateTime(2022, 8, 9, 11, 30, 0);
DateTime end = DateTime(2022, 8, 9, 12, 30, 0);
NSMDOAgent mdoAgent;
Integer associateId = 1993;
Bool allDayEvent = false;
String additionalInfo = "[DT:" + start.toString("DD2/MM2/YY4 HH24:MI2:SS2") + "]|[DT:" + end.toString("DD2/MM2/YY4 HH24:MI2:SS2") + "]|" + allDayEvent.toInteger().toString() + "|" + associateId.toString();
foreach (NSMDOListItem listItem in mdoAgent.GetList("NextAvailableTime", true, additionalInfo, false))
{
printLine(listItem.GetName());
}You can call this MDO list using the REST api
Huh, interesting. If you provide it with a weekday, the function presumes that you want an open booking on a weekday. If you pick a saturday, it assumes you want an open booking on specifically a saturday - and the same for sunday.
I wonder if this is system specific or if it's a more general thing.
This functionality is worth knowing about if you're booking appointments during a cron job run on the weekend and you use the servers date as basis.
Oh, and additional info for other people:
The solution can throw a Netserver exception related to whether the date format is correct. It'll complain about an issue with UI culture, so make sure that the format matches the one used internally by the superoffice instance. It will simply say something like, 'expected DateTime, got xxxxxxx'.
Thanks for that Tony, that's great to know!
I wanted to also let you all know that I think I discovered a bug.
When I adapted David's code for my circumstances, I reused the 'foreach' loop. This worked fine both when the script was called from service and via a rest-api call - but when I then tried to run a trace on the script after I used the rest-api call, the trace refused to load; it effectively timed out. Which was quite curious, since the code actually did what it was supposed to.
When I replaced the foreach loop with a traditional for loop, that's all it took to get 'trace' to work again even when run via a rest api call.
I have a hunch it may be some kind of concurrency error, as the rest api allows concurrent script execution, and I imagine this could have some kind of effect on a loop accessing the list - but I'm not sure - I assume CRM Script is interpreted, and not cross compiled, as foreach loops, when compiled into an intermediate language 'just in time', are typically replaced with while loops, so it may be that there is some kind of functionality that differs between a traditional for loop and the foreach loop - and that this somehow comes into play when executed via a rest call.
Unless the content of the for-each loop also somehow relates to the bug, it should actually reproduce with Davids code, a rest api call to activate it, and a trace. Let me know if you need my version of the for-each loop.