В этом посте мы рассмотрим концепции модели данных и то, как она применяется к искусству реактивного программирования (бизнес-логика). Мы рассмотрим изменения в нашей корзине и представим цены BOGO (buy-one-get-one). Модель реактивного программирования Espresso Logic использует комбинацию объявлений и JavaScript для сущностей (таблиц) и атрибутов (столбцов) для создания API приложений масштаба предприятия. Последней версией революционной технологии Espresso Logic является возможность открытия нескольких соединений RDBMS. Это позволяет на уровне определений API виртуализации и ресурсов (т. Е. Пользовательских конечных точек API) создавать удивительные решения для бизнес-требований. Иногда модель данных может потребоваться изменить или новую базу данных, таблицы,и добавлены атрибуты для введения новых функций, поддерживаемых моделью реактивного программирования Espresso Logic.
Таблицы, столбцы и ключи
При создании бизнес-приложения или подключении к существующей базе данных SQL базовая концепция таблиц и столбцов может быть представлена в виде электронной таблицы необработанных данных. При разработке бизнес-приложения или расширении существующей унаследованной модели первым шагом является определение первичного ключа (ключей) для каждой строки. Способность идентифицировать уникальную строку очень важна для правильной работы Espresso Logic. Без указанного первичного ключа обновление и удаление будет затруднено, если не невозможно выполнить. Первичный ключ также используется в объявлениях внешнего ключа (например, в отношениях) для соединения родителя с потомком. Espresso Logic будет использовать эти собственные отношения и пользовательские объявления для обеспечения ссылочной целостности (RI) на сервере в базах данных. Атрибуты используются для вывода столбцов (формулы, суммы, числа,родительская копия), а сущности содержат перекрестные проверки столбцов.
Значения по умолчанию
Следующим шагом в процессе может быть определение значений по умолчанию, которые требуются или рассчитываются для каждого столбца. Одним из наиболее распространенных шаблонов является дата создания и изменения. Дата создания по умолчанию установлена на сегодняшний день и не изменяется, а дата изменения обновляется при каждом обновлении записи. В терминах бизнес-логики это будет формула столбца (для параметра createDT задано возвращение row.createdDT == null? New Date (): row.createdDT), где в качестве измененного элемента DT задано возвращение нового Date () независимо от того, какое изменение состояния происходит). Эти новые правила могут быть применены поверх существующей базы данных и будут применяться на сервере независимо от настроек значения по умолчанию для базы данных (или в дополнение к ним). Вывод столбцов (формула) может быть более сложным и включать полный диапазон параметров JavaScript, включая if / then / else или вызов других ресурсов REST или кода Java / JavaScript.
Отношения
Если каждая таблица представляет страницу электронной таблицы, то рабочая книга будет представлять собой набор таблиц со «ссылками», которые объединяют или выполняют поиск связанных данных. Отношение определяется как внешний ключ от дочерней таблицы к родительской таблице. Отношения могут включать один или несколько атрибутов столбца. Преимущество предопределенного отношения заключается в том, что оно помогает механизму SQL оптимизировать объединения и проверять связанные данные (RI). Отношения часто описываются ролями, которые они играют от родителя к ребенку. Типичным примером является поле кода состояния в коллекции адресов. Родительская таблица StateCodeTypes имеет первичный ключ stateCode, а таблица адресов имеет ссылку на внешний ключ из stateCode. Espresso Logic использует эти отношения для проверки данных перед их записью на диск.Это означает, что вы можете добавлять новые таблицы и новые определяемые пользователем отношения для поиска и проверки без необходимости изменения существующей схемы. (См. Эспрессо ЛогикаСтраница поддержки нескольких баз данных ). Редактор ресурсов и Live Browser используют эти взаимосвязи для создания новых вложенных документов, а также для отображения родительских / дочерних данных и поиска данных внешнего ключа.
Производные (SUMS, COUNT, MIN, MAX)
Когда вы видите электронную таблицу с промежуточными итогами и итогами — это формула, выраженная в столбце или строке. В нашем примере мы знаем, что можем добавить формулу к каждой отдельной записи, чтобы создать итоги строк. Для промежуточных итогов столбцов мы введем нового родителятаблица для хранения этих совокупных значений. Типичным примером является корзина покупок, в которой сумма заказа является родительской, а детали корзины — отдельными строками. У нашего родителя могут быть столбцы для суммирования общей суммы строки заказа, примененных скидок и любых налоговых или транспортных расходов, связанных со строкой. Подсчет может быть применен к родителю (например, у вас есть 3 предмета в вашей корзине). Если ваша существующая схема базы данных не может быть легко изменена, просто добавьте новую родительскую таблицу в новую базу данных и создайте пользовательскую связь между родителем и существующим дочерним элементом. Новые записи в дочернем элементе могут автоматически создавать родительский элемент (управлять родительским правилом) и создавать эти агрегаты. На самом деле, концепция многоуровневого объединения очень проста в реализации. Недели могут сводиться к месяцам, месяцам к четвертям и четвертям к годам.Бизнес-логика может создать такой же анализ всей вашей базы данных SQL, который вы могли бы рассмотреть, используя электронную таблицу. Если требуется вывод строки, необходимо изменить модель, чтобы добавить новый столбец.
Родительская копия
Одно специальное правило — родительская копия — используя связь с родительской таблицей, значение родительского атрибута можно скопировать в выбранный дочерний столбец. Типичным примером является корзина покупок, мы хотим скопировать текущую цену товара вниз в позицию корзины, чтобы можно было использовать цену для расчета итоговой строки (цена * количество). Если родительская цена изменится в будущем — это не повлияет на ребенка. Если вам нужно распространить изменения на всех детей, используйте событие, описанное ниже.
Validations
One of the most powerful concepts in Espresso Logic is the validation. This is a special type of rule that can test the content and context of the row being processed and determine if the entire business transaction should be accepted or rejected. This can be used to validate required values, determine if values are within acceptable ranges, or perform external credit checks using the full access of Java and JavaScript libraries. The validation works within the scope of a business logic transaction, that is, it all passes (accept when) or the entire business transaction is rolled back and a user defined validation message is returned.
Events
Espresso Logic is a REST Server and responds to various event requests to retrieve data GET(Request Event, Row Event, Response Event) and insert/update POST/PUT(Early Event, Event, Commit Event) as part of an event process lifecycle. Events use the JavaScript language and have full access to other JavaScript and Java libraries. These events also have full access to the entity model (tables and columns) as well as relationships to parent entities. Using Espresso Logic helper functions, Events can be used to insert data into other entities (createPersistentBean, getBeanByPrimaryKey), fire REST requests (restGET, restPOST), to other services, lookup data from other entities (getRowsByQuery) or resources (getResource). A common pattern is to audit changes and insert the oldRow values into the audit table. Another example is to send an email when the order payment is confirmed and another one when the order is shipped (orderPaid and orderShipped flags are used to trigger these state change events).
Putting it together
In our shopping cart example, we have been asked to add a new pricing policy (Buy one Get one – BOGO) to our existing application. We are also told that the max limit per order is 4 and the max limit per customer is 10. Further, these rules only apply to selected products during a selected date range. To make it more difficult our DBA told us we cannot change the data model – only the logic. We will need to create new tables to hold the BOGO products, effective dates, and limits. We will also need a global customer bogo table to count lifetime limits. Our new tables will be joined to our existing shopping cart, product, and the new pricing rules will be applied to our existing formula.
Logic Summary
Our Bogo_product table has effective dates, product ID, and bogo limits for orders and customers, and the discount price. It is up to the rule itself to determine if a product is used in the BOGO calculation and is within the effective date. The count on the CustomerBogo table is used to determine the lifetime limit. These tables can be added to the existing database or a new database. Now the formula to determine the line item price is invoked to lookup the price and then ask if this is a bogo product within the effective range.
var rows = logicContext.getRowsByQuery("bogo_product",
"select * from bogo_product where id <> "+row.productID +' and effStartDT >= getDate() and effEndDate <= getDate());
for (var i = 0; i < rows.length; i++)
log.debug('Found bogo_product:' + rows[i].name);
Validations are used to enforce lifetime customer and client line item purchase amounts. In Espresso Logic, rules are added and invoked based on a dependency tree of columns and entities. This means you do not need to invoke or ‘call’ rules, rules are invoked when state change occurs (e.g. insert or update). The image below is an example of the Logic Design Studio relationship editor used to join tables between new and existing databases.
Summary
Espresso Logic can connect to one or more of your existing SQL and NoSQL databases and create an instant REST API for tables, views, and stored procedures. Business Logic can be placed on top of existing entities and attributes or new tables can be added to new databases and joined into your legacy system to create new REST API endpoints that provide sophisticated business transaction logic. Data Model concepts like adding new tables or altering tables to add columns to support business rules is an integral part of the design lifecycle of reactive programming.