Version 6.4.0 Not able to serialise CallRecord Object.
Expected behavior
Proper Serialisation of Call Record object into Json string.
Actual behavior
CallRecord Object getting serialised to empty json string "{}"
Steps to reproduce the behavior
final GraphServiceClient graphServiceClient = new GraphServiceClient(TestData.MSGraphTestData.clientSecretCredential(),
TestData.MSGraphTestData.DEFAULT_SCOPE);
final CallRecord callRecord = graphServiceClient
.communications()
.callRecords()
.byCallRecordId(callRecordId)
.get();
try (SerializationWriter writer = graphServiceClient
.getRequestAdapter()
.getSerializationWriterFactory()
.getSerializationWriter(MediaType.APPLICATION_JSON_VALUE)) {
writer.writeObjectValue("", callRecord);
try (InputStream stream = writer.getSerializedContent()) {
final String json = new String(Compatibility.readAllBytes(stream), StandardCharsets.UTF_8);
System.out.println(json);
}
} catch (final Exception e) {
System.out.println(e);
}
Can someone please help with this ?
@ramsessanchez Can you please help with this ?
Hi @priya2395 Thanks for using the SDK and for reaching out. This is expected, by default only the changed properties will be serialized.
adding this line before you call the writeObjectValue method should solve your issue.
callRecord.getBackingStore().setReturnOnlyChangedValues(false):
Hi @baywet callRecord.getBackingStore().getReturnOnlyChangedValues is already false in the call record object returned by graphserviceclient. callRecord.getBackingStore().getIsInitializationCompleted is coming as true from graph service client Still its not working.
If I set getIsInitializationCompleted as false then its serialising fields in callRecord class. However, not the fields in nested classes like organizer, sessions etc.
below is the response I get :
{"id":"e523d2ed-2966-4b6b-925b-754a88034cc5","@odata.context":"https://graph.microsoft.com/v1.0/$metadata#communications/callRecords/$entity","endDateTime":"2020-02-25T18:52:46.7640013Z","lastModifiedDateTime":"2020-02-25T19:00:24.582757Z","modalities":["audio"],"organizer":{},"participants":[{},{}],"sessions":[{}],"startDateTime":"2020-02-25T18:52:21.2169889Z","type":"peerToPeer","version":1}
If I serialise using jackson or any other serialiser, I am getting json structure with backingstore, fieldSerialisers, additionalData etc. However, I want a json structure similiar to postman API response. This was working with the default serialiser in microsoft graph v5 version. But is not working with v6. @baywet Can you please help with this?
Hello team,
Can someone please help with this issue ?
The Serialization methods from those two classes probably need additional overloads that accept a boolean parameter "SerializeUnchangedFields" https://github.com/microsoft/kiota-java/blob/main/components/abstractions/src/main/java/com/microsoft/kiota/serialization/KiotaJsonSerialization.java https://github.com/microsoft/kiota-java/blob/main/components/abstractions/src/main/java/com/microsoft/kiota/serialization/KiotaSerialization.java
Whenever this boolean parameter is passed to true, we'd need a coroutine that'd recursively walk the tree and flip the backing store setting so the user (you) don't have to do it yourself.
Is that something you're interested in sending a pull request for?
@baywet For the quick solution, is it fine if we use new JsonSerializationWriter() instead of graphServiceClient .getRequestAdapter().getSerializationWriterFactory().getSerializationWriter(MediaType.APPLICATION_JSON_VALUE) ?
Its serialising all properties not just the changed ones. However ms graph sdk has kiota-serialisation library as runtime dependency. So, we need to add it as compile time dependency separately in our project.
Just wanted to check if cause dependency version conflict ?
That's a good workaround and it shouldn't cause any issues. For other readers, by instantiating a new factory/writer, you don't get the proxies injected by the backing store, and so all backing store behaviour is disabled on those serializers when they are used.
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.