Абстрактный класс/метод/способ для проверки XML (Soap ответов)

Вопрос скорее по Best Practies чем именно по SoapUI. С этом тулом работаю долго, так что хотелось бы услышать нетривиальные ответы/примеры. 

Есть несколько веб-сервисов, которые по сути предоставляют SOAP интерфейс к другой системе/API/хранилищу (DB, SVN, LDAP, Fileserver etc). Ответы от сервисов могут быть разными и сложноструктурированными, с большим количством нод и субнод, значений (аттрибуты, как правило не используются).

Пример ответа (неполный :) ):

 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <getJobResponse xmlns:ns3="http://eterra.com/asf/schema/common/v1" xmlns:ns2="http://eterra.com/asf/schema/tdm/common/v1" xmlns="http://eterra.com/asf/contract/tdm/dm/workflow/v1">
         <JobVO>
            <CreateTime>2012-11-09T20:09:28.532-08:00</CreateTime>
            <Creator>mjcowley@vapps.esca.com</Creator>
            <Description>build</Description>
            <Id>16101</Id>
            <JobProperties>
               <Key>tdm.persistentParms</Key>
               <StringValue>tdm.siteCode,tdm.empVersion,tdm.componentDescription,tdm.habitatVersion,tdm.componentDependencies,tdm.buildNumber,tdm.componentVersion,tdm.userId,tdm.componentGroupName,tdm.environmentCode,tdm.componentName,tdm.componentTypeCode,tdm.jobId</StringValue>
            </JobProperties>
            <JobProperties>
               <Key>tdm.empVersion</Key>
               <StringValue>3.0</StringValue>
            </JobProperties>
            <JobProperties>
               <Key>tdm.ets.dir</Key>
               <StringValue>C:/eterra/e-terrasource</StringValue>
            </JobProperties>
            <Name>BuildEtb-16101</Name>
            <StartTime>2012-11-09T20:09:28.696-08:00</StartTime>
            <Status>Completed</Status>
            <Steps>
               <Id>16164</Id>
               <Name>initialize</Name>
               <ParentJobId>16101</ParentJobId>
               <StartTime>2012-11-09T20:09:28.826-08:00</StartTime>
               <Status>Completed</Status>
               <StopTime>2012-11-09T20:09:41.313-08:00</StopTime>
               <Tasks>
                  <Actor>tdm-agent@vapps.esca.com</Actor>
                  <Cancelled>false</Cancelled>
                  <End>2012-11-09T20:09:41.303-08:00</End>
                  <ExecutionHost>wx64mdl01:8080</ExecutionHost>
                  <JobId>16101</JobId>
                  <Open>false</Open>
                  <ParentStepId>16164</ParentStepId>
                  <Start>2012-11-09T20:09:28.904-08:00</Start>
                  <Suspended>false</Suspended>
                  <TaskInstanceId>16165</TaskInstanceId>
                  <TaskName>initialize</TaskName>
                  <Type>Command</Type>
               </Tasks>
            </Steps>
            <StopTime>2012-11-09T20:09:52.143-08:00</StopTime>
            <TimeoutLimit>-1</TimeoutLimit>
            <WorkflowId>333</WorkflowId>
         </JobVO>
      </getJobResponse>
   </soap:Body>
</soap:Envelope>
 
Название полей в БД/хранилище/API не совпадает с таковыми в ответе от сервиса (by design). Форматы значений естественно тоже разные (но это не так страшно).
Писать на каждую ноду XML и поле в БД свою строку кода для проверки значений, совсем не хочется. Хочется иметь таблицу развязки, с названием полей в ответе, в БД/хранилище/API и типом данных. Всё это я успешно сделал и работает. Теперь после изменений в названиях полей Soap ответа или структуре БД я меняю только таблицу развязки и все скрипты проверки работают снова. Т.к. у нас вездесущий scrum, то меняем мы это каждый билд :), а проектов у нас в комманде много, а людей мало. Ну это как и у всех, собсна.
Вопрос состоит в следующем, делал ли, кто нибудь такую таблицу развязки, чтобы учитывалась еще и иерархическая структура ответа? То есть таблица развязки должна учитывать не только название и типы полей, но также и структуру ответа. Скрипт проверки должен понимать эту развязку с учетом иерархии объектов. Согласно этого конечно придется строить и запросы к хранилищу (DB, SVN, LDAP, API etc) напрямую. Также нужно учитывать, что в разных нодах (классах хрнилища) можгут быть одинаковые названия полей (субнодов). К примеру Name или ID очень популярное название поля:)
Вообщем, вопрос  бОльше для обсуждения наверное, ну а вдруг кто придумал универсальное решение и поделится с нами.
 
 
 

Можна например что сделать, парсить сабноду в обьект. Если не парситься в обьект значит структура уже нарушена, имхо ассерт не пройдет.

JSON парсить в обьекти можна JAckson-ом, XML - ищите в нете. Просто если кусок стринга не розпарситься етой либой в обьект класса вашей заданой структури то вальнеться ексепшн, которий можна перехватить в тесте например - ето считаю и будет критерием проверки на архитектуру.

Наверное я не до конца рассказал что именно надо. Для проверки именно структуры (и частично значений) XML есть xsd что умело юзает SoapUI в SchemaCompliance asserion.

Вопрос не в проверке структуры, а в проверке сложно-структурированной XML на основании хранилища данных.

К примеру имеем 2 таблички в БД

Groups и Peoples. Связь для простоты один ко многим (в одной группе несколько людей). Джойнятся таблички по простому ключу. Итого WS выдаст структуру типа

 

<root>
  <group>group1
    <user>user1</user>
    <user>user2</user>
  </group>
  <group>group2
    <user>user3</user>
    <user>user4</user>
  </group>
</root>
 
В БД поля называются не так как в ответе от WS. Задача нарисоваьт таблицу развязки, согласно которой результат работы SQL-запроса (который строится тоже на основании развязки) будет похож на ответ от сервиса.
Мне пока что видится только один вариант. Рисовать таблицу развязки с такой же структуруй как ответ от WS и на основании этой структуры стоить коллекцию (MapOfMap Map<Map>и т.д.), а потом уже итерироватся по коллекции и парсить XML. То есть по сути создавать такую же XML  как и ответ от сервиса и сравнивать их.

Можно пойти по другому пути, учитывая, что SOAP сервисы - это по сути API с распределенной инфраструктурой и все эти XML-и это просто очередное представление некоторого типа данных. Любой из этих типов данных можно представить в виде множества таблиц со своими связями (эту структуру можно получить генерацией диаграмм классов). Соответственно, у вас есть 2 структуры: структура исходной базы и структура данных-ответов на запросы. Между этими структурами есть связь. Чтобы проверить целостность данных, нужно сделать запросы к обеим структурам и привести обе структуры к общему виду (не обязательно это представление одной из структур, это может быть любое производное представление). В итоге у нас есть 2 таблицы одной струкруры и нам останется только сравнить их (различными сортировками и группировками их можно подравнять). А дальше идет цикл сравнения.

В этом случае сравнение упрощается, так как сравнивать структурированные плоские таблицы проше, чем XML со вложенными структурами, но в целом для реализации данного подхода SOAP UI - не самое лучшее решение.

Да в принципе понятно все идеологически. Надо привести данные к виду ответа от сервиса и сравнить. Универсального решения я так и не нашел, но для каждого ответа который нужно проверять я строю структуру такого же вида как и ответ на основании первичного источника данныхи уже рекурсивно проверяю ответ.
А почему Вы считаете что SoapUI плохо подходит для проверки Soap ответов?

Я считаю, что SoapUI плохо подходит для реализации подхода, который описал я, так как я сделал больше упор именно на структуры данных с отвязкой от XML. Поскольку SoapUI не преобразует ответы в пригодные для работы типы данных напрямую, то из-за этого я и высказался, что SoapUI плохо с такой задачей справится.

Если глянуть шире и посмотреть, как SOAP сервисы используются, то тут уже возникнет отдельный вопрос, а насколько хорошо SOAP UI подходит для тестирования этого всего. Но это уже отдельная тема, на самом деле.