Defining Ensemble Messages

Introduction

A message body can be any persistent object.

In practice, you often create a subclass of Ens.Util.RequestBodyMethodsOpens in a new tab or Ens.Util.ResponseBodyMethodsOpens in a new tab and add properties. This creates the standard message body. If you use these classes, you have easy access to the various built-in features for viewing the contents of messages from the Management Portal. These features help developers and administrators detect errors in a running production, especially if the production uses message content to determine where the message should be sent.

Some electronic documents — Electronic Data Interchange (EDI) formats such as HL7 or X12 — contain data that is arbitrarily long and complex. In this case, it is better to use an alternative class, a class that represents an Ensemble virtual document. In this case, the message body does not have a set of properties to contain the message contents. For details, see Ensemble Virtual Documents.

Most of the examples in this book assume a standard message body, with a relatively small number of message properties.

Creating a Simple Message Body Class

To create a message class (to be used as the message body), create a class that:

• Extends either Ens.Util.RequestBodyMethodsOpens in a new tab or Ens.Util.ResponseBodyMethodsOpens in a new tab.

• Contains properties as needed to represent elements of data to be carried in the message.

The following shows a simple example:

The following shows a simple example:

Class Demo.Loan.Msg.CreditRatingResponse Extends Ens.Util.ResponseBodyMethods
{

Property TaxID As %String;

Property CreditRating As %Integer;

}

The class can also contain methods. For example:

Class Demo.Loan.Msg.Application Extends Ens.Util.RequestBodyMethods
{

Property Amount As %Integer;
Property Name As %String;
Property TaxID As %String;
Property Nationality As %String;
Property BusinessOperationType As %String;
Property Destination As %String;

Method RecordNumber() As %String
{
  If ..%Id()="" Do ..%Save()
  Quit ..%Id()
}

Method GetRecordNumberText(pFormatAsHTML As %Boolean = 0) As %String
{
  Set tCRLF=$s(pFormatAsHTML:"<br>",1:$c(13,10))
  Set tText=""
  Set tText=tText_"Your loan application has been received,"_tCRLF
  Set tText=tText_"and is being processed."_tCRLF
  Set tText=tText_"Your record number is "_..RecordNumber()_"."_tCRLF
  Set tText=tText_"You'll receive a reply from FindRate"_tCRLF
  Set tText=tText_"within 2 business days."_tCRLF
  Set tText=tText_"Thank you for applying with FindRate."_tCRLF
  Quit tText
}

}

Another option is to create a custom message class, but when you do this, it is important to define the class so that the messages are stored only in their own table so that message searches can be fast. To do this, use %PersistentOpens in a new tab as the primary superclass, followed by either Ens.RequestOpens in a new tab or Ens.ResponseOpens in a new tab, depending on whether this is a request message or a response message. For example:

Class Demo.Loan.Msg.CreditRatingResponse Extends (%Persistent, Ens.Response)
{

Property TaxID As %String;

Property CreditRating As %Integer;

}

(The USEEXTENTSET and DEFAULTGLOBAL class parameters provide other ways of ensuring that the messages are stored in their own table; for details, see the class reference for %PersistentOpens in a new tab.)

Yet another option is to simply create a class that is based on a persistent class and that optionally includes %XML.AdaptorOpens in a new tab as another superclass. (%XML.AdaptorOpens in a new tab provides support for displaying the message in XML form in the Management Portal.)

Creating a Complex Message Body Class

In the previous example, the message body class contained only simple properties. In some cases, you may need to define properties that use other classes. If so, you should carefully consider what to do when you purge message bodies (as described in Managing Ensemble).

When you purge message bodies, Ensemble deletes only the specific message body object. For example, consider the following message class:

Class MyApp.Messages.Person Extends Ens.Util.ResponseBodyMethods
{

Property Name As %String;

Property MRN As %String;

Property BirthDate As %Date;

Property Address As MyApp.Messages.Address;

}

The Address class is as follows:

Class MyApp.Messages.Address Extends %Persistent
{

Property StreetAddress As %String;

Property City As %String;

Property State As %String;

Property ZIP As %String;

}

In this case, if you purge message bodies, Ensemble deletes instances of MyApp.Messages.Person, but does not delete instances of MyApp.Messages.Address.

If your message body class uses other classes as properties and if your application requires that any referenced objects should also be purged, use one of the following approaches:

• Make sure that the referenced classes are serial. For example, redefine the Address class as follows:

  Class MyApp.Messages.Address Extends %SerialObject
  {
  ...
  }
  

  

  In this case, the data for the Address class is stored as part of the Person class (and is thus automatically purged at the same time).

• Define the property as a suitable relationship. See “Persistent Behavior of Relationships” in the chapter “Relationships” in Using Caché Objects.

• Add a delete trigger or %OnDelete() method to the message class so that this class deletes the appropriate records in the referenced classes.

• Optionally include %XML.AdaptorOpens in a new tab as a superclass so that the properties defined in the referenced class can be displayed in the Management Portal.