Complex Transaction Processing

You can perform complex transaction processing when a transaction requires a mix of different types of verbs, such as GET, POST, and PUT, that REST is telling the server to take on a row in the request. Use @metadata action tags.
lac31
You can perform complex transaction processing when a transaction requires a mix of different types of verbs, such as GET, POST, and PUT, that REST is telling the server to take on a row in the request. Use 
@metadata
 action tags.
With
@metadata
 action tags, you can:
  • Specify greater granularity. The tags designate the verb to take on each row. This can provide substantial value in choreographing the persistence actions taken in processing a request.
  • Create and link related data using 
    CA Live API Creator
    services. The services apply to how to process the rows in the request. Reactive logic then applies to each of these row.
  • Link child rows to parent rows, without the requirement for the client to supply 
    autonum
     identifier (which they may not know) by inserting 
    @metadata
     action tags. You can use parent sub-resources with these actions.
In this article:
Metadata Actions Tags
You can use the following metadata action tags:
DELETE
For example, you can delete using the
name
field as a unique key:
  {
    "@metadata" : {
       "action":"
DELETE
",
       "checksum":"override",
       
"key":"name"
     },
     "name":"David 2",
     "some_val":202}
For more information about this metadata action tag, see DELETE.
LOOKUP
For more information about using this metadata action tag, see Lookup Metadata Action.
INSERT
For more information:
UPDATE
For more information about this metadata action tag, see PUT.
MERGE_INSERT
For more information about this metadata action tag, see MERGE_INSERT Metadata Action Tag.
Mix and Match Metadata Action Tags in a Request
You can use different metadata action tags in the same request. The following code snippet shows an example. In this example, the Customer object is inserted (using the
INSERT
metadata action tag), the Product object is updated (using the
UPDATE
 metadata action tag), and the Address object is deleted (using the
DELETE
metadata action tag):
[
  {
    "@metadata": {
      "entity": "Customer",
      "action": "
INSERT
"
     },
     "name": "Acme Inc",
     "credit_limit": 5000
[
  },
  {
    "@metadata": {
      "href": "https://foo.my.espressologic.com/rest/foo/bar/v1/Product/123",
      "checksum": "123456789ABCDEF",
      "action": "
UPDATE
"
    },
    "unit_price": 0.99
  },
  {
    "@metadata": {
      "href": "https://foo.my.espressologic.com/rest/foo/bar/v1/Address/456",
      "checksum": "123456789ABCDEF",
      "action": "
DELETE
"
     }
  }
]
Find or Update Rows from External Sources using the Metadata Key
It is a common pattern to find or update rows from external sources, where the system key is not known. This is often because the actual key might be a database-generated number, unknown to external systems or businesses.
For example, the Business to Business (B2B) sample test posts an order for Products. Products are identified by a
ProductID
. Since external systems cannot know such names, it uses the 
LOOKUP
 metadata action tag, for example:
{
  "CustomerNumber":"VINET",
  "Items":[
  {
    "Product":{
      "@metadata":{
        "action":
"LOOKUP",
        "key":"ProductName"
      },
      "ProductName":"Pavlova"
   },
   "Quantity":1
},
CA Live API Creator
 uses the
key
 to find a Product row by
ProductName
, extracts its
ProductID
, and stores this in the
Items
row being inserted. The 
LOOKUP
 action automates this. While the fields comprising the key typically comprise a unique key, this is not strictly required. The only requirement is that the find returns exactly one row.
The key is available in the 
LOOKUP
 and the 
MERGE_INSERT
 metadata action tags.