Business to Business Example

This Business to Business (B2B) sample is a data integration example that illustrates a small but non-trivial system, built using . This article provides a high-level overview of  and covers beginning functionality and concepts.
lac32
This Business to Business (B2B) sample is a data integration example that illustrates a small but non-trivial system, built using 
CA Live API Creator
. This article provides a high-level overview of 
CA Live API Creator
 and covers beginning functionality and concepts.
For additional logistics and training resources, see Explore B2B.
 The B2B sample is not included with the the single-user demonstration package of 
CA Live API Creator
 that is based on Jetty (demonstration package). You must install this the sample.
For more information about how to install the B2B sample, see Install B2B.
In this article:
 
 
3
 
 
The B2B sample illustrates a typical API Server that processes inputs from multiple (omni-channel) sources:
  1.  
    Processes omni-channel requests, such as a partner order.
     API Server accepts requests from multiple channels, such as mobile devices, partners, "catching" webhooks, and web apps. The API definition is not the same as the B2B schema, providing mapping and transformation logic.
    For more information about webhooks, see Integrate Systems and Data.
  2.  
    Enforces business logic. 
    Business policy for logic and security includes internal processing such as credit checks, and external processing such as sending alerts to shippers, by posting a request in an agreed-upon API format. This API definition does not match the B2B schema.
  3.  
    Integration
    . Your API can "throw" (send) webhooks to other systems (for example, to a supplier in an agreed-upon format that may not match your schema), and integrate multiple databases.
  4.  
    Provides UI.
     Partners (shippers, suppliers) can view their information from a mobile device, PC, etc.
The following diagram shows the flow for this system:
  CA Technologies  
These systems are complex and time-consuming to build, using traditional approaches based on interface documentation (for example, RAML), frameworks (for example, Jersey, Jackson, JPA, etc.), and integrated development environments (IDEs) to build a substantial amount of business logic. Use the B2B sample to explore the 
CA Live API Creator
 alternative, which requires about a dozen lines of JavaScript, a dozen rules, and five point-and-click resources. 
The complete implementation using 
CA Live API Creator
 consists of several rules and a few lines of JavaScript. The B2B sample uses the Northwind database as the underlying database, to simplify installation.
The server for demonstration package is pre-configured for the Northwind sample database. If you have installed this version of 
CA Live API Creator
, no additional configuration steps are required to access this database.
B2B Learning Guide
The B2B sample is a key resource in understanding what 
CA Live API Creator
 can do and how to use it. The following resources are provided to help you ramp as quickly as possible:
  •  
    Install the B2B Sample
     
  •  
    Explore the B2B Samples (Fundamentals)
    The samples illustrate introductory 
    CA Live API Creator
     functionality and concepts such as API Creation, logic, and extensibility.
    For more information about these introductory functionality and concepts, see the "Explore B2B (Fundamentals)" section.
  •  
    Explore the B2B Samples (Intermediate)
     
    The samples also illustrate deeper 
    CA Live API Creator
     concepts such as metadata tags, multi-database resources, functions, security, Data Explorer, and scripted API deployment that you need for your own APIs.
    For more information about these intermediate functionality and concepts, see Explore B2B.
  •  
    Readiness Lab
     
    After exploring the introductory and intermediate 
    CA Live API Creator
     functionality and concepts, you can verify your readiness to use 
    CA Live API Creator
     using the set of labs that are built using this API. The labs are located in the 
    samples/
    b2b/readinessLabs/
    readinessLabs/Readiness - CA Live API Creator.docx
     file (and in the PDF file), located in your install folder.
    You have completed the first lab by installing the B2B sample and testing the API.
  •  
    Other B2B Test Scripts
    A key strength of the API architecture is that you can call APIs in various ways, across languages and architectures. You can test the B2B API using most any program. This includes the REST Lab, Data Explorer, scripts such as cURL or the Command-Line Interface, or programs such as Node.js, Python, or PHP. Your API is therefore useful not only for integration, but web apps, scripting, and a host of other applications. Your install zip includes examples of each of the testing approaches.
    For more information about how to test the B2B API, see Other B2B Test Scripts.
Explore B2B (Fundamentals)
The B2B sample illustrates key 
CA Live API Creator
 features. The B2B sample API provides an excellent study in creating an API back end. Explore the B2B sample to see the code/rules used to create the B2B Northwind API.
  1. An order is posted through the 
    PartnerOrder
     resource. This resource provides the mapping and transformation logic to process the order from a partner.
  2. The post activates the business logic. You can compute order totals with product-based discounts, adjust the customer balance, and ensure that the credit limit is not exceeded using about ten rules. The 
    Supplier Alert
     event rule alerts the 
    Pavlov
     supplier (about 12 lines), checks what was ordered. If it is a product that is the 
    Pavlov
     supplier supplies, this event rule posts an alert to the 
    B2B Pavlov
     API. The 
    SupplierAlert
     custom resource is used for mapping and translation logic.
While this application contains only a few dozen lines of logic and code, it illustrates other patterns common to B2B systems. For example, the 
SupplierInfo
 resource integrates multiple databases and enforces row-level security. Partners can safely and directly access their data.
For more information about the 
SupplierInfo
 resource, see the 
b2b/scs/projects/test/node/verifySupplier.js
 JavaScript source code file.
At the operational level, the install script illustrates a typical team development scenario. The 
scs
 folder mimics how you might maintain API Creator objects in a source control system. It includes loadable libraries that are used for extensibility. The installation scripts provide examples of command line scripting, and API access from Node, Python, and PHP programs, or test it in the REST Lab, as explained in the 
SupplierInfo
 resource comments.
For more information about team development, see Team Development.
API Creation and Customization
The first step is to create your API and customize ("shape") it as required. Swagger documentation is always available. Use it with various tools to generate objects in C#, Java, etc.
Connect to Create Default API
The B2B system connects to the database and creates endpoints for each table, view, and stored procedure. There is no code generation or deploy. The B2B system was created using the install scripts.
Resources: Mapping and Transformation
The following image shows the resource Attributes tab:
  Screen Shot 2017-01-06 at 5.08.27 PM.png
The default API is a good start, but it conforms to your schema. Usually, you will want to "shape" your API. For example, API agreements with partners typically do not match internal schema definitions. Custom resources provide key services to map API agreements onto your database and logic:
  • Choose/rename columns, which is a simple approach to mapping and transformation logic. In the previous image, 
    PartnerOrder.Order
    ID
     
     is aliased to 
    Order
    Number
     
    .
  • Specify resource nesting so that B2B requests can include multiple kinds of data, such as the Order and Items.
  • Use non-persistent attributes (NPA) in resources. For example, in the 
    OrderSummary
     resource, the SalesRep's 
    fullName
     is an NPA.
  • Combine parent subresources into the containing resource. For example, in the 
    OrderSummary
     resource, the 
    Product
     information appears with the 
    Order_DetailList
     properties.
  • Custom resources reuse the logic on the underlying tables.
For more information:
Logic
Logic ensures the integrity of your data when update requests are made. For example, we want to:
  • Verify that orders do not exceed customers' credit limits.
  • Provide discounts for healthy orders.
  • Post requests to the 
    Pavlov
     supplier when orders are received for their products.
The following sections illustrate how to perform this type of multi-table logic and integration with other systems. In API Creator, the logic is done by way of spreadsheet-like reactive logic and extended with server-side JavaScript.
For more information about reactive logic rules, see the conceptual background of Logic.
Declarative Reactive Rules
Rules are spreadsheet-like expressions (coded in JavaScript) defined on tables and columns. API Server automatically applies them (reacts) to all submitted updates. You do not need to call them.
The following executable rules apply to all custom resources. Rules can reduce server-side integrity enforcement by over an order of magnitude. Rules provide clear and concise user-readable logic instead of tedious code. The requirements are captured as topics (in the following image, as blue, green, and red boxes) and linked to the logic for traceability:
Screen Shot 2016-12-26 at 5.28.11 PM.png
The 
B2B Northwind
 API includes the following topics:
  • Check Credit.
     Rolls up items and orders to verify that the customer's credit limit is not exceeded. (If a validation is exceeded, the request results in an exception and the transaction is rolled back.)
  • Healthy Food Discount.
     Provides a discount to customers ordering things like fruits and fish.
  • Supplier Alert.
     When orders are detected for the 
    Pavlov
     supplier, the business agreement requires that the order is posted to the 
    Pavlov
     supplier.
  • Shipper Alert.
     When orders have an assigned shipping company, alert them to order changes.
For more information:
Extensibility: Table Events
Reactive logic is powerful. Extensibility is provided by server-side JavaScript, to ensure that there are no limits.
For more information:
The following Orders commit event rule posts a webhook to alert shippers of order changes. The following commit event rule code posts an order and 
OrderDetails
 to the 
Suppliers
 webhook:
var shipper = row.FK_Orders_Shippers;
if (shipper !== null) { // resource defines transform: cols, aliases, related objects
var transform = logicContext.transformCurrentRow("ShipperAPIDef");
B2B.sendToWebHook(transform, shipper.webHookURL);
}
The Orders event logic is available with code completion. This code example is available from the event rule code editor.
This commit event rule illustrates several key patterns of B2B integration:
  • Transformation logic.
     A common integration pattern is to use resources for mapping and translation, leveraging their ability to choose/rename attributes and related objects. The 
    logicContext
     object's 
    transformCurrentRow
     method transforms a table row to a resource instance and is typically called in an event rule. This method provides transformation logic to select/rename attributes and related objects. The format of the post is defined by the custom resource 
    ShipperAPIDef
  • Event handling. 
    Event rules react to database changes, regardless of the execution path.
  • Posting.
     The post is done in the 
    sendToWebHook()
     method.
  • Webhook target. 
    Shippers can register for webhooks by way of self-service APIs that set 
    shipper.webHookURL
    .
    For more information about this pattern, see the "Security" section in Explore B2B.
For more information:
Extensibility: Loadable Libraries
If you detect patterns in your logic, you can provide reusable solutions that rules can invoke. The code in the following image provides a reusable function that implements a webhook:
CA Technologies  
Libraries are generic services. You can use your own applications to transform a table row into a business object (as defined by a resource) and post it to the registered webhook (the supplier's URL). You can load logic libraries, such as 
transformToWebHook
.
For more information about how to load logic libraries into your API, see Logic Libraries.