Внутренняя ошибка сервера при доступе к данным через OData
Ковыряюсь потихоньку с задачей, для которой нужен доступ к данным, хранимым в облаке Creatio, по протоколу OData. И наткнулся на регулярные сообщения сервера о внутренних ошибках:
Обращаюсь по URL https:// ... .terrasoft.ru/0/odata/ - работает
https:// ... .terrasoft.ru/0/odata/Case - работает
https:// ... .terrasoft.ru/0/odata/Case( какой-то Id, который я ранее узнал ) - работает
https:// ... .terrasoft.ru/0/odata/Case( ... )/Subject - работает. И для других свойств тоже работает
https:// ... .terrasoft.ru/0/odata/Case( ... )/ModifiedBy - работает (хотя в описании объектов OData это не "Property", а "NavigationProperty")
https:// ... .terrasoft.ru/0/odata/Case( ... )/CaseMessageHistoryCollectionByCase (это уже не просто NavigationProperty, а NavigationProperty с установкой "Type=Collection( ... )") - не работает. Возвращает статус "500 Internal Server Error " и сообщение " An error has occurred."
Ситуация стабильная. Ошибка возникает всегда, вне зависимости от того, к какой конкретно записи в Case я обращаюсь. Более того, ошибка возникает при обращении к любому свойству, которое должно вернуть коллекцию.
И аналогичная ошибка возникает при обращении https:// ... .terrasoft.ru/0/odata/CaseMessageHistory?$filter=CaseId eq ... Опять же, возникает стабильно.
Вопрос: как со всем этим бороться?
Нравится
Григорий, все примеры по работе с OData в Creatio есть тут. Возможно, что-то делаете не так, как предложено использовать.
Без конкретных примеров неработающих запросов затруднительно сказать, что с ними не так.
Зверев Александр,
Я написал конкретные примеры запросов. Точками заменены только адрес сайта и переменный параметр для выборки конкретной записи (который я выяснил из предыдущих экспериментов). Все остальное написано один в один с тем, что посылается на сервер.
За ссылки на примеры спасибо. Но при сравнении их со своими попытками я не увидел никакой разницы.
Так что вопрос остается в силе.
Например, вот рабочий запрос с eq:
/0/odata/SysSchema?$filter=ManagerName%20eq%20%27EntitySchemaManager%27Аналогично можно выбрать из CaseMessageHistory, отфильтровав по CaseId:
/0/odata/CaseMessageHistory?$filter=Case/Id%20eq%20ceef8012-3806-4431-b62b-102270f6fcc9
Зверев Александр, За пример с CaseMessageHistory огромное спасибо. Так сработало. А вот аналогичная (по смыслу) конструкция
/0/odata/CaseMessageHistory?$filter=CaseId eq ceef8012-3806-4431-b62b-102270f6fcc9
(отличается отсутствием слэша между "Case" и "Id") приводит к внутренней ошибке сервера
Зверев Александр,
поставить слэш вполне можно. (Хотя и непонятно, на каком основании он там нужен, и почему без него не работает). А мне, кстати говоря, интересно стало: у Вас без слэша что будет - нормальная работа или ошибка?
Вам нужно получить данные или таки отладить/взломать систему?
В примерах слэш есть.
У меня на таком же запросе будет ровно то же, что и у Вас.
Зверев Александр,
в первую очередь мне нужно получить данные.
А во вторую очередь я хочу понять, почему не работает то, что (по моим представлениям, составленным на основе документации по Odata) должно работать. Ибо от этого зависит, насколько я в своей дальнейшей работе могу полагаться на документацию.
Григорий Шпаков,
На документацию можете не полагаться, надо разбираться самому методом проб и ошибок.
Григорий, документация есть по ссылке, которую привёл в верхнем ответе. Нужно в первую очередь пологаться на варианты, предложенные в ней, а не на сторонние, которые могут предлагать способы, которые этим движком не реализованы.
Если необходимость конкретного написания вызвана интеграцией с каким-то сторонним софтом, который умеет только так, то опишите случай подробнее, чтобы зарегистрировать пожелание на новые версии.