Как зафиксировать каждую транзакцию БД в узле сопоставления в IIB Toolkit?

Question

У меня есть JSON тело типа Array. Теперь каждое тело будет вставлено в БД по одному. Существует ограничение на использование узла отображения только в том случае, если он имеет GUI. Но в узле отображения я не могу изменить транзакцию с automati c на любое другое значение. В результате, когда первое тело вставляется в БД, а второе выходит из строя, первое также получает откат. Как спроектировать узел сопоставления таким образом, чтобы, когда 1-й был успешным, он также был зафиксирован? или если 1-й сбой, будет также попытаться вставить второй?

вот запрос JSON массива по крайней мере 2 элементов:

[
    {
        "batch_id": 2019,
        "trx_no": "test",
        "sys_ref_no": "test",
        "trx_line_num": 1,
        "trx_start_date": "test",
        "trx_post_on_date": "test",
        "trx_post_on_date_dr": "06-APR-20",
        "company_code": "test",
        "company_id": 1,
        "shop_num": "test",
        "shop_id": 1,
        "pos_num": "test",
        "pos_id": 1,
        "tax_type": "test",
        "tax_code": "test",
        "tax_rate": 1,
        "currency_code": "test",
        "currency_id": 1,
        "tax_amt": 1,
        "tax_id": 1,
        "tax_base_amt": 1,
        "tax_exchange_rate": 1,
        "tax_exchange_date": "test",
        "tax_exchange_type": "test",
        "status": "test",
        "error_message": "test",
        "creation_date": "06-APR-20",
        "created_by": 1,
        "last_update_date": "06-APR-20",
        "last_update_by": 1,
        "data_source": "test",
        "request_id": 1,
        "billing_intf_flag": "test",
        "n_attribute1": 1,
        "n_attribute2": 1,
        "n_attribute3": 1,
        "c_attribute1": "test",
        "c_attribute2": "test",
        "c_attribute3": "test",
        "d_attribute1": "test",
        "d_attribute2": "test",
        "d_attribute3": "test",
        "d_attribute1_dr": "06-APR-20",
        "d_attribute2_dr": "06-APR-20",
        "d_attribute3_dr": "06-APR-20"
    },
    {
        "batch_id": 2020,
        "trx_no": "test",
        "sys_ref_no": "test",
        "trx_line_num": 1,
        "trx_start_date": "test",
        "trx_post_on_date": "test",
        "trx_post_on_date_dr": "06-APR-20",
        "company_code": "test",
        "company_id": 1,
        "shop_num": "test",
        "shop_id": 1,
        "pos_num": "test",
        "pos_id": 1,
        "tax_type": "test",
        "tax_code": "test",
        "tax_rate": 1,
        "currency_code": "test",
        "currency_id": 1,
        "tax_amt": 1,
        "tax_id": 1,
        "tax_base_amt": 1,
        "tax_exchange_rate": 1,
        "tax_exchange_date": "test",
        "tax_exchange_type": "test",
        "status": "test",
        "error_message": "test",
        "creation_date": "06-APR-20",
        "created_by": 1,
        "last_update_date": "06-APR-20",
        "last_update_by": 1,
        "data_source": "test",
        "request_id": 1,
        "billing_intf_flag": "test",
        "n_attribute1": 1,
        "n_attribute2": 1,
        "n_attribute3": 1,
        "c_attribute1": "test",
        "c_attribute2": "test",
        "c_attribute3": "test",
        "d_attribute1": "test",
        "d_attribute2": "test",
        "d_attribute3": "test",
        "d_attribute1_dr": "06-APR-20",
        "d_attribute2_dr": "06-APR-20",
        "d_attribute3_dr": "06-APR-20"
    }
]

Answer 1

Поскольку не нужно обрабатывать это JSON как одну единицу работы, т. Е. Зафиксировать в db или откатить, вы можете разделить работу на два отдельных потока сообщений. Первый поток сообщений разделяет входные данные JSON с несколькими дочерними элементами на отдельные JSON только с одним узлом. Передайте этот отдельный JSON узел (тело) следующему потоку сообщений, который использует узел сопоставления для вставки в базу данных. Таким образом, вы можете обойти ваше ограничение использования узла отображения.

Answer 2

Существует ограничение на использование узла отображения только в том случае, если он имеет GUI.

Эту проблему было бы легко решить с помощью узла Compute и небольшого количества E * 1013. *. Насколько я знаю, это невозможно с помощью узла Mapping. Таким образом, либо это ограничение будет ослаблено, либо требование об удалении независимых транзакций должно быть удалено.

В общем, плохая идея - создавать жесткие правила относительно того, какой язык преобразования IIB использовать, потому что это приводит к неловким ситуациям. как этот. Можно использовать предпочтительный язык или по умолчанию язык, если это допустимо для других языков. Ваша ситуация на самом деле немного необычна. Для E SQL более распространено (но все еще неразумно) быть единственным и единственным разрешенным языком!