Example of an Application Class Accessing Implementation Binds

The following partial code shows how an application class can access any of its implementation binds.

method GetCaseID Local any &CaseID;
  &CaseID = &ioAccessMethod.getBindValueByName("CASE_ID");
  Local EOCF_CLF_DL:Runtime:Results:ResultsScalar &oResultsScalar;
  &oResultsScalar = create EOCF_CLF_DL:Runtime:Results:ResultsScalar(&CaseID);
      &ioAccessMethod.Results = &oResultsScalar;
end-method;

The application class does not need to know how the data is retrieved and passed by the data library engine. The data could have been passed by the calling application, defined as a constant in context definition, or defined as a term and resolved by the data library engine. The application class can retrieve the data either by position or by name.

/* BO_ID is the name of the implementation bind;the bind name specified
 here matches the one to be specified at the time of registering the
 implemenation in &nBOID = &ioAccessMethod.getBindValueByName("BO_ID");
 Here the request is made to retieve the value for the first bind. */
&nBOID = &ioAccessMethod.getBindValueByPosition(1);

Another way that the calling application can pass additional information to implementations or policy actions is to have the calling application use the addUserVariable method to add the information to the context object. To access this information, the application class uses the getUserVariable method.

For example:

&AdditionalData = &oAccessMethod.AMContext.getUserVariable("ExtraInfo);

Note:

The shape of the data received by an application class using any of the previous methods will be a PeopleCode Any object. Therefore, the application class is responsible for converting the object to the appropriate data type before the value is consumed. If the application class has a method to be invoked by the data library engine, then that method should not require any parameters.