Input Context Objects

In business logic metadata or in the code it is often desirable to refer to a piece of information from an outside source.  This may be a common piece of information that's useful to a variety of your process flow inputs, or it may be a piece of information that's cumbersome to pass around to every process flow that may need it.  Input Context Objects are designed to solve this problem. Aptify provides two Input Context objects today.

1. Request Input Context - for getting a property from the end point input payload
2. Authenticated Attributes Input Context - for getting information about the current user.  

Using Input Context Data in Business Logic Metadata

By now you should have seen examples of using Input Context data in your business logic metadata. The overview on Business Logic Metadata covers this.  But we will recap it again here. You refer to the particular input context object you want in metadata by prefacing it with the @ symbol and removing 'InputContext' from the name. Then you add a period. And then you put whatever property you want from that context object after it. For example:

If you have an end point with an input property of OrderId

@Request.OrderId

If you want a property from the authenticated attributes:

@AuthenticatedAttributes.AuthenticatedPrincipalRecordId

Out of the box the authenticated attributes provides the following properties

• AuthenticatedPrincipalEntity - the name of the entity for the authenticated principal. Currently, this is always 'Persons'.
• AuthenticatedPrincipalRecordId - the record id in the AuthenticatedPrincipalEntity entity. If the authenticated user is tied to Persons record 1, this value will be 1.
• ServiceApplicationName - the name of the Service Application executing this request.
• IsAnonymous - true if the AuthenticatedPrinicpalRecordId is the record id for the anonymous user of this service application.

Using Input Context Data in Code

This area is still being worked on. For now, you should prefer using the context objects through metadata rather than depending on them in code.  But some information is provided for now.  

The code backing every context object implements the IInputContext interface.  Obtaining an instance of IInputContext should be done through an instance of IInputContextFactory.  For Example:

_iInputContextFactory.GetInputContext("AuthenticatedAttributes").GetValue<string>("ServiceApplicationName")

The factory object will need to be injected through dependency injection, or explicitly asked for with the type resolver.  

Creating a new input context object

New input context objects can be created and registered with the framework using Dependency Injection. Context objects should implement the Endpoints.IInputContext interface. The class should be named {contextName}InputContext, where {contextName} is the value you plan on using in the metadata. If you want a context named UserCompanyInformation your class would be named UserCompanyInformationInputContext. You would register it with the DI container in your installer with the following call:

container.RegisterType<IInputContext, UserCompanyInformationInputContext>(typeof(UserCompanyInformationInputContext).FullName);

If you cannot conform to this naming convention you can override IInputContext resolution by registering your own instance of IInputContextFactory.

Considerations when creating new input context objects

The framework does no caching of the context object values after lookup. If the lookup is expensive it is on your implementation to ensure this is efficient enough to meet your needs. The number of context objects that exist and are cached will increase the memory footprint of your web server.