We now come to the first really significant definition–the letter of credit asset:

 asset LetterOfCredit identified by letterId {
   o String letterId
   --> Customer applicant
   --> Customer beneficiary
   --> Bank issuingBank
   --> Bank exportingBank
   o Rule[] rules
   o ProductDetails productDetails
   o String [] evidence
   --> Person [] approval
   o LetterStatus status
   o String closeReason optional
 }

Let's spend a little time on this definition, as it's both central to understanding the business network, and Hyperledger Composer in particular.

First, note the asset keyword. It indicates that what follows is a data structure that describes an asset. It's just like a type definition in a normal programming language, but with some special characteristics that we'll see later.

We can see that the asset is of the LetterOfCredit type. In this example, we only have one asset type–in more sophisticated examples, we'd have more types of assets. For example, we could extend this model to include a Shipment asset, and a Payment asset:

asset Shipment
asset Payment 

For now, let's skip the identified by clause, moving to the first element in the asset definition:

o String letterId

The letter o indicates that this field is a simple attribute of the asset. It's a slightly strange way of indicating this, so just think of it as a decoration. This first attribute is the letterId. Recall that when a letter is created in the business network, a unique ID is assigned to it. If you recall, in our example, we had letterId L64516AM or L74812PM. This is indicated by the field having the String type–lots of types are available, as we'll see. We can see that this definition allows us to associate a human-readable identifier with the asset. Note that this must be a unique identifier!

Let's now return to the identified by clause:

identified by letterId

Now we can understand that this indicates that the letterId attribute is the one by which the asset is uniquely identified. It's a simple but powerful idea that relates closely to the real-world. For example, a car might have a Vehicle Identification Number (VIN) that uniquely identifies it.

Let's move to the next attribute:

--> Customer applicant

The first thing we notice is the --> decorator! (Type it as two dashes and a greater than symbol on your keyboard). This is a reference attribute–it points to something! In the case of a letter, it points to a different type, Customer, and the name of this element is applicant. See how the reference concept is a little more complex than the simple attribute we saw earlier–that's because it does more work. This field is saying that the letter has an applicant which is of the Customer type, and that you need to look it up via this reference.

In our example, an instance of a letter will point to Alice, as she's a customer of Dinero Bank who makes an application. Notice that this a reference attribute refers to a different object in the business network. This idea of a reference is very powerful–it allows assets to point to other assets, as well as participants, and the same for participants. With references, we're able to represent the rich structures that we see in the world. It means that we can create assets that can be combined and divided, and the same is possible for participants. In our example, we use the reference to see who has applied for a letter by navigating the reference. Again, we can see that this model is very bank-centric. We'll see later that Customer is in fact a participant, and we'll see how participants, such as Alice, are defined. But for now, let's stay with the asset definition.

As we discussed in Business Networks, our application uses a simple way of modeling ownership–in the real-world, it is often an associative reference. We could most easily model this more sophisticated associative relationship as an OwnershipRecord, which pointed to an asset and pointed to a participant if we wished to do so:

asset OwnershipRecord identified by recordId {
   o String recordId
   --> LetterOfCredit letter
   --> Customer letterOwner

We can instantly see the power of this approach. We're able to model the relationships that exist in the real-world, making our applications more realistic and therefore easier to use. For our purposes, our current model is perfectly adequate.

Let's move to the next field:

--> Customer beneficiary

This is a very similar field to the previous one, and in our example, an instance of this element would be Bob. There's no need to spend time on this definition. It's important, of course, but it just points the letter at Bob. If you recall, our application always has the two counterparties associated with a letter.

The next two fields have a similar structure, but we're going to spend a little more time discussing them:

--> Bank issuingBank
--> Bank exportingBank

We can see that these fields are also references to other objects, and we might suspect they are participants, given their names–issuingBank and exportingBank! Examples instances of these types are Dinero Bank and Eastwood Bank, who act on behalf of Alice and Bob, respectively.

With these first four reference fields, we've modeled the very rich structure of the asset. We've shown that a letter of credit really has four participants involved in it. We've given them symbolic names and types, and shown how they relate to the asset. Moreover, we've done it without writing any code. We're going to have to do that a little later, but for now, notice how we've captured the fundamental nature of a letter of credit in our model. It's worth spending a little time really understanding this point.

We're only going to consider one more field in the asset definition because hopefully you're getting the hang of this! It's an important field:

o LetterStatus status

Remember those ENUMs that were defined right at the top of the file? Good! This is the field that's going to contain those different values, such as AWAITING_APPROVAL or READY_FOR_PAYMENT. You're often, if not always, going to have fields and enumerations like this in your business network, because they capture in a very simple form where you are in the business process you're modeling. If you're comfortable with workflows or finite state machines, you might like to think of these as states–they are a very important idea.