Assign Division to Schedule

Hi,

I m using .NET SDK and i tried to create a schedule.
I must set Division property but i get AuthzDivision object from division's API.

How to set Division property to create a schedule ?

Regards,

Benjamin

How are you trying to create a schedule? The schedule should not require you telling it a Division because a Schedule is created inside a Business Unit and inherits the Division of that Business Unit.

Examples;

POST /api/v2/workforcemanagement/businessunits/{businessUnitId}/weeks/{weekId}/schedules

POST /api/v2/workforcemanagement/businessunits/{businessUnitId}/weeks/{weekId}/schedules/generate

You don't create a schedule object and populate it manually, you would use one of the two methods above (or Copy, or a Get) and then make changes to the objects they create through their ScheduleId

I m talking about routing schedule /api/v2/architect/schedules

Hi Benjamin,

You have to copy the division id out of the AuthZDivision object and into the Schedule object for the call /api/v2/architect/schedules. The AuthZDivision object is a completely different class so you can not set the division information on the POST /api/v2/architect/schedules call because they are two different types (even though they are the same information).

Hope that helps.

Thanks,
John

Hi John,

The issue is that there is no API that returns an object of type Division and the Id of the division is read-only, so i can't create it.
I found a workaround by serializing/deserializing Authzdivision to Division.
However I always have an error (bad request) when I call the schedule API, it works fine with postman with the same payload.

Regards,

Benjamin

Please open a case with Genesys Cloud Care to report this issue. The contract defines the id property as readonly, which is why the SDK doesn't allow you to set it. Once that bug is reported and fixed in the API's contract, it will be fixed in the SDKs as well.

You can also just deserialize your own JSON like {"id":"0000..."}. You might also be able to extend the Division class with your own type that overrides the id property with a setter. I'm pretty rusty with .NET, but I think that's possible.

Can you share the correlation ID from the bad request?

Hi Benjamin,

Sorry if I am not understanding you.

Wouldnt you just create a ININ.PureCloudApi.Model.Division object with the data you got back from the AuthzDivision object and then set that on the ININ.PureCloudApi.Model.Schedule object before you pass it into `ArchitectApi.PostArchitectSchedules'? Are you getting some kind of error when you do this using the .NET SDK?

Could you post the .NET SDK calls you are making? There is a chance that there could be a problem with the SDK, but seeing the actual code might help me better understand what you are trying to do? Make sure you scrub it of any sensitive information.

Thanks,
John Carnell
Manager, Developer Engagement

Hi,

@John, it s not possible to create a Division object because Id's property is read only. I found a dirty workaround :slight_smile:

.NET Request body:

var schedule = new Schedule{
Description = s.Description,
End = s.End,
Name = s.Name,
Rrule = s.Rrule,
Start = s.Start,
Division = JsonConvert.DeserializeObject(o.ToString())};

Json Request Body:

{
"name": "24by7_Schedule15",
"division": {
"id": "9bc42d7e-bc47-4c9d-b948-2d269899d7e0",
"name": "Home"
},
"start": "2022-02-20T00:00:00",
"end": "2024-12-31T23:59:59"
}

Response:

{"message":"The request could not be understood by the server due to malformed syntax.","code":"bad.request","status":400,"contextId":"9eb8f70c-953f-4314-a823-25f9cfd1f2d7","details":[],"errors":[]}

Benjamin

It's failing to parse a date. It doesn't say which property, but the error message is:

Invalid format: "2022-02-19T23:00:00Z" is malformed at "Z"

This would also be good to report to Care when reporting the readonly id property; this error should be returned to the client.

It is unclear why the /api/v2/architect/schedules is expecting a Division object when a Division ID would be sufficient. Looks like a dot Net SDK issue if the POST /api/v2/architect/schedules doesn't execute successfully.

Hi Benjamin,

You found a bug. I am going to explain what is happening here in the post as I am going to need you to open a Care ticket. This will ensure the bug gets appropriately tracked and prioritized. The issue is the scheduling development team did not properly annotate their swagger documentation with the right object type. The Division object that they annotated their swagger docs with is a read-only object. What they should have used is a WritableDivision object. We generate our SDKs off the Swagger docs and as a result, by them using a Division object (which is read-only) we only generate a getter for Division and not the setter.

However, the raw REST call will happily take your division information because the WritableDivision and the Division as types do not get enforced at the REST API level and not at the SDK level. The actual API expects you to set the division id. I was looking at our documentation and not the actually generated .NET code and our documentation does not mark properties as read-only (and it never has). It just notes the property name.

Here is what I am going to need you to do.

Open a ticket with Care that explains your problem and reference this post in the ticket. This ticket will need to be assigned to the engineering team responsible for the Schedules API to fix and then the SDK can be generated properly.

I am going to open two internal tickets that will help make these types of issues more explicit:

  1. See if we can mark read-only properties as read-only within the SDK documentation so the docs are more explicit.
  2. Open a ticket to fix our API explorer. Read-only properties should have been excluded from the API explorer.

The workaround right now is to directly call the API. Thanks, @tim.smith for walking me through this. Thanks, Benjamin for being patient while working through this.

Thanks,
John Carnell
Manager, Developer Engagement

Hi John, the Case 0003126355 has been logged with Genesys Care and it has a reference to this forum link.
Many thanks for following up

Hi Hichem,

No worries. Sorry for the delay in getting this sorted out.

  • John

Hi Hichem and Benjamin, I am working with Care and the dev team to get this resolved.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.