This is all very impressive, but how does it work–where's the logic that implements these transactions that manipulate participants and assets, and creates events? To understand this, we need to look at the transaction programs–the code that runs when transaction are submitted to the network that refer to these assets, participants, and events.

The transaction code is held in a Script File, and if you select Script File on the Define tab, you'll see the following:

This is the code that implements transactions! Today, Hyperledger Composer uses JavaScript to implement these functions, and that's what you're looking at on this page–JavaScript. If you page through the script file, you'll see that there's a function for every transaction defined in the model file.

 Let's examine one of the transactions we've been playing with up to this point–the InitialApplication transaction. Notice how the function starts:

/**
  * Create the LOC asset
  * @param {org.example.loc.InitialApplication} initalAppliation - the InitialApplication transaction
  * @transaction
  */
 async function initialApplication(application) {

The comments and the first line of program code are effectively saying the following function implements the InitialApplication transaction, which takes an org.example.loc.InitialApplication type, and assigns it to the locally-scoped application variable. In a nutshell, it connects program logic to the transaction definition we saw in the model file.

The first important line of code is the following:

const letter = factory.newResource(namespace, 'LetterOfCredit', application.letterId);

factory.newResource() creates a new local LetterOfCredit in the org.example.loc namespace, using the identifier supplied by the caller of the function in the input application.letterId transaction variable. This statement assigns the result of this function to a local letter variable.

It's important to understand that this statement has not created a letter in the business network; factory.newResource() merely creates a correctly shaped JavaScript object that can now be manipulated by the following subsequent logic, and after it is properly formed using the input provided by the caller (for example, the application being used by Alice), it can be added to the business network!
 
Notice how applicant and beneficiary are assigned:

letter.applicant = factory.newRelationship(namespace, 'Customer', application.applicant.getIdentifier());
letter.beneficiary = factory.newRelationship(namespace, 'Customer', application.beneficiary.getIdentifier());

The transaction makes sure that Alice and Bob's identifiers are placed correctly in the letter. In our network, application.applicant.getIdentifier() would resolve to resource:org.example.loc.Customer#alice or resource:org.example.loc.Customer#bob. The transaction logic systematically constructs the letter of credit using the supplied input and information already stored in the business network.

Next, notice how issuingBank and exportingBank navigate via the participant to their bank. The program logic is navigating the references in the participant and asset definitions to do this:

letter.issuingBank = factory.newRelationship(namespace, 'Bank', application.applicant.bank.getIdentifier());
letter.exportingBank = factory.newRelationship(namespace, 'Bank', application.beneficiary.bank.getIdentifier());

We can see in these statements how the transaction has to use the structure that was defined in the model. It can add any proprietary business logic to do this, but it must conform to this structure. Examine each line that assigns to letter and see whether you can understand what's happening in these terms. It takes a little getting used to, but it's really important to understand this–the transaction is transforming the business network from one state to another using this logic.

Notice the last statement of the letter assignment:

letter.status = 'AWAITING_APPROVAL';

See how the enum types are being used to set the initial state of the letter. 

The next really important statement in the function is the following:

 await assetRegistry.add(letter);

This now adds the letter to the business network! At this point, we have created a new application for a letter of credit in the business network. The letter we created in local storage has been sent to the network, and is now a live asset that points to the participants and assets in the network.

Finally, we emit an event to signify that the transaction has taken place:

const applicationEvent = factory.newEvent(namespace, 'InitialApplicationEvent'),
applicationEvent.loc = letter;
emit(applicationEvent);

As with the letter, we create a local event of the right shape–an InitialApplicationEvent, complete its details, and emit() it. Examine the different transactions and their logic to become comfortable with the precise processing of each transaction–you'll be richly rewarded for this effort.