Неверное имя объекта - PullRequest
Новая
       66

Неверное имя объекта

0 голосов
/ 12 июня 2018

Мы вызываем Microsoft Exchange, чтобы установить расширенное свойство, которое в нашем случае является уникальным guid 

microsoft.exchange.webservices.data.core.exception.service.remote.ServiceResponseException: An internal server error occurred. The operation failed., Invalid named property

. Оно прекрасно работало до сих пор, когда некоторые из наших пользователей сталкиваются с вышеуказанной проблемой ....

 val uId = getUniqueId();    

val emailExtendedPropDef = new ExtendedPropertyDefinition(uId,"uniqueId", MapiPropertyType.String)
    try {
      email.setExtendedProperty(emailExtendedPropDef, uId.toString)
      email.sendAndSaveCopy()
    } catch {
      case e: Exception =>
        error(s"Exception in setting extended property for user $from", e)
        throw e
    }

пытаясь найти основную причину проблемы, мы также думаем, что это может быть связано с регулированием в Microsoft Exchange для расширенных свойств (не уверен, как доказать, действительно ли оно регулирует) любую помощь, чтобы указатьмы в правильном направлении окажем большую помощь

Наш вариант использования заключается в том, чтобы получить письмо, когда клиент хочет ответить, мы хотим получить это конкретное письмо, которое будет включено в ответ пользователя ... в настоящее времямы используем uid для достижения этого ....

мы использовали код согласно документации здесь

https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/dd633654(v%3Dexchg.80)

, а также документации здесь

https://github.com/OfficeDev/ews-java-api/wiki/Getting-Started-Guide#extended-properties

Обновление: согласно комментариям мы понимаем, что мы должны рассматривать extendedProperty как определение столбца и обновлятьменя столбец ... но мы не могли понять, как этого добиться, как ... Любые примеры кода, которые укажут нам правильное направление, будут очень полезны

Последнее обновление: мы удалили некоторые изExtendedPropertyDefinition, но все еще с тем же недопустимым свойством, может кто-нибудь, пожалуйста, укажет нам правильное направление

1 Ответ

0 голосов
/ 12 июня 2018

Безопасно ли говорить, что getUniqueId возвращает разные guid при каждом вызове?Если так, то это проблема.Думайте о Guid для расширенной опоры как о пространстве имен.Хранилище Exchange ограничивает количество настраиваемых расширенных реквизитов примерно 32 КБ на почтовый ящик.Таким образом, вы, вероятно, достигаете этого предела.Но кроме этого, основная причина создания расширенного свойства заключается в том, что вы можете обратиться к нему позже.Но если вы в основном отбрасываете пространство имен каждый раз, вы оставляете осиротевшие предметы на предметах.Не понимая ваш конкретный сценарий, я могу только сказать, что Guid следует рассматривать как пространство имен.Выберите один для вашего приложения / компании / сценария и жестко закодируйте его.Они создают все именованные реквизиты, которые вы хотите в этом пространстве имен.Например, «MyProp / String» в пространстве имен Guid 1 - это свойство, отличное от «MyProp / String» в пространстве имен Guid 2.

...