Исключение ApikitRuntime: недопустимый дескриптор API + синтаксический анализатор Raml; необработанное исключение: null, что это значит?

Question

У меня есть сгенерированный apikit-маршрутизатор, который направляет в файл raml и генерирует потоки xml из него.

<when expression="message.inboundProperties.role == &quot;backoffice&quot;"> <apikit:router config-ref="backoffice-config" doc:name="Backoffice APIKit Router"/></when> ...

Когда я начал запускать проект, я получил ошибку

org.mule.module.apikit.exception.ApikitRuntimeException: недопустимый дескриптор API - найдены ошибки: 1 синтаксический анализатор Raml, необработанное исключение: null

Теперь мой вопрос: может ли кто-нибудь объяснить мне, что означает это исключение? Я хочу определить, что вызывает исключение.

Я пытался найти документацию по такого рода исключениям, и я не нашел документации для этого (если есть, пожалуйста, помогите мне найти ссылку).

[редактировать]

Мое определение RAML - просто макет для тестирования:

#%RAML 1.0
title: mocktest
mediaType: application/json

/mocktest:
  description: Describes a list of Employees.

  get:
    description: Request Body for a new Employee Post Request.
    responses: 
      200:
        description: OK Responsebody for a new EMployee POst Req.
        body: 
          application/json:
            example:  |
              {
              "employeeId":2231,
              "employeeName":"Lorem Ipsum"
              }

Если это поможет: я не добавил http-слушатель в поток apikit-router, следовательно, теоретически (мой) он будет использовать основной HTTP-слушатель для маршрутизации к сгенерированным xml потокам из файла RAML.

Основная цель: направить сообщение в зависимости от свойства inboundProperty, является ли его значение backoffice или client, причину, по которой apikit-router находится внутри подпотока выбора.

Answer 1

Хорошо, я понимаю, что вы пытаетесь сделать, спасибо за дополнительную информацию.

RAML - это "контракт" для клиентов, которые хотят использовать ваш сервис. В нем изложено, как называть ваши услуги; каковы адреса конечной точки, какие методы использовать, в каком формате должна быть полезная нагрузка моего запроса. Как и какая информация ожидается обратно. Со всей информацией в файле RAML они должны быть в состоянии интегрироваться с вашим сервисом, даже не связываясь с разработчиком.

MuleSoft тесно интегрировал RAML в цикл разработки API, которому вы хотели бы следовать. Одним из аспектов этого является компонент APIkit Router. Он автоматически направляет запросы между интерфейсом (вашим файлом RAML) и внутренними потоками на основе HTTP-запроса.

Однако в вашем сценарии вы добавляете конечную точку http и пользовательскую логику перед APIkit. Эти изменения нарушают принудительную связь между файлом RAML и вашим кодом. Обратите внимание, что ваш пользовательский поток принимает входящие свойства "роль", но он не указан в файле RAML. Ваш клиент не будет знать, что это свойство существует при подключении к вашему сервису. Mulesoft хочет предотвратить это несоответствие, и именно поэтому вы получаете ошибку.

Я бы порекомендовал изменить ваш файл RAML так:

...
get:
    description: Request Body for a new Employee Post Request.
    queryParameters:
      role: 
    responses:
...

и ваши потоки будут

<flow name="get:/mocktest:backoffice-config">
    <choice doc:name="Choice">
        <when expression="#[message.inboundProperties.role == 'backoffice']">..</when>
        <otherwise>...</otherwise>
    </choice>
</flow>

Надеюсь, это имеет смысл.