Fautore API: fauAppReg

Applications are the end points between which data is transferred. Both sending and receiving applications must be registered with Fautore.

Overview

This page details the operation and use of the "fauAppReg" function. Please see External Applications for an overview of the application and agent registration process. Applications are registered with Fautore as data destinations. Applications are registered to provide the host owner options for moving data to and from external applications. Application agents are also registered to Fautore just like applications themselves.


Upon application approval by an application manager a permission named for the application is created.

Approved applications are made available to Tribe Members granted permission the associated permission. Tribe members must enroll in the available application to be able to transact data using that application. Enrollment is the process of providing criterion specific to that user for the registered application.

Fautore provides a "preferred" flag indicating the app is preferred by the Tribe member end user for receiving data. The host owner has the ultimate authority over how data is delivered to each requesting end user.

Limitations

NATTNone At This Time

Relevant Tribe Configuration Parameters

NATTNone At This Time

Registration Criteria

Function: fauRegApp

Source:
All data is provided by registering application. Alternatively, Fautore screens could be developed at a future time for the manual registration of an application.

Request Spec
{ "Func": "fauRegApp" { 
      "AppName":     r-str(45)  Descriptive application name, spaces allowed
      "Description": r-str(512) Info to aid enablement decision by app manager
      "UserName":    r-str(45)  User name of registering member, must verify,
      "AppPush":     r-boo      Flag (0,1) indicating if application pushes data to Fautore
      "FauPull":     r-boo      Flag (0,1) indicating if Fautore pulls data from application
      "DefVals": {
         "Computer": o-str(45)  Host name or IP address of application host
         "Port":     o-int      Application port number on application host computer
         "AppUser":  o-str(45)  Application user name on remote computer
         "AppPass":  o-str(45)  Application user password on remote computer
         "Interval": o-int      Interval at which application interaction should occur
      }
      "AppVals" [
         {
            "TechName": r-str  Technical name for described field
            "Length":  r-int      Length of dynamic application field
            "Value":   o-str(128) Value for application specific field
            "DispName" r-str(64)  Field name in dynamically created forms
            "DataType" r-str(16)  Data type stored in the dynamic application variable
         }
     ]
}
Request Example
$json = '{ "Func": "fauRegApp",
      "AppName":     "fauEmail",
      "Description": "Email utility to treat a mail server as a contributing team member",
      "UserName":    "Crazed1",
      "AppPush":     1,
      "FauPull":     0,
      "DefVals":
         {"Computer": "Thor.cichosz.org",
         "Port":     26,
         "AppUser":  "Marvin",
         "AppPass":  "R0bot",
         "Interval": 300 },
      "AppVals": [
         {
             "TechName": "catalog"
             "DispName": "Catalog",
             "DataType": "Str",
             "Length": 42,
             "Value": "Spring"
         },
         {
            "TechName": "persKey"
            "DispName": "Personal Key",
            "DataType": "Str",
            "Length": 69,
            "Value": "ajhdfyuqw487qqweiaisfg6480403er"
         }
     ]
}';


Returns:

The response returned is a 2 field JSON structure:

MsgId:
  • Positive numbers indicate success
  • Negative numbers indicate rejection
  • NULL = Request failure, programmatic error

Mesg:

  • Descriptive text explaining the MsgId

Upon Success:

  • MsgId = 1
  • Mesg = Fautore id for the application reference


Upon Rejection:

  • MsgId = negative reason code (table of codes TBD)
  • Mesg = Text of message describing reason for rejection (i.e. Application already registered for user.)


Upon Failure:

  • NULL

Data Mapping

Data accepted by the fauAppReg function stores it's data as indicated in the below table.

Note:

  • The RegApps table must be populated before the Apps table
  • The RegApps:AppId generated for the application is reused in the Apps table

JSON Table Field Comments
AppName RegApps AppName Straight copy from JSON to table.
Description RegApps Description Straight copy from JSON to table.
UserName RegApps UserName Verified against "User" table before insertion.
AppPush RegApps AppPush Straight copy from JSON to table.
FauPull RegApps FauPull Straight copy from JSON to table.
DefVals - - Pointer to default values for the application. These values are supplied to Tribe Members as defaults when they enroll in application use.
Computer Apps Computer The hostname or IP address of the computer hosting the application. This value must be verified as being within the FOD.
Port Apps Port The port on the host computer by which the application is accessed.
AppUser Apps AppUser Login id used to access the application.
AppPass Apps AppPass Password associated with AppUser. This is a problem point. we need a way to store this information securely, yet still be able to pass it back to the application later n a form it understads.
Interval Apps Interval Number of seconds between iterations of accessing the application.
- Apps User_UID This value is not passed from the application. This is always "default" to indicate this is the default value set for the application. There should always be 1 and only 1 of these records associate with any application.
- Apps RegApps_AppId The unique application id assigned when data was stored to the RegApp table.

Workflows

The below workflows describe the process for registering an aplpication for use with a Fautore Tribe, configuring it for use and configuring it into a Tribe instruction.

Application Registration

Registration is the process of making an application available to Fautore. A registered application is not useable until after it has been configured and activited by a Application ManagerAn application manager is any tribe member with the "Manage Apps" privelege..

  1. Application queries Fautore well known port in the IANA "User Ports" range with a registration request.
  2. Fautore returns Dynamic port address of Registration Service
  3. Application sends registration criteria to Registration Service
  4. Registration service verifies provided TUID exists
  5. Registration service verifies provided password matches for the TUID
  6. Registration service Verifies provided TUID has privileges to register application
  7. Registration service creates Unique Fautore ID (UFID) for application
  8. Registration service creates a record for the application in the "Apps" table
    1. Unique Fautore Identifier (UFID)
    2. Tribe User Id of registering user
    3. AppPush value
    4. FauPull value
    5. Registration date
    6. Default for "Computer" if provided (IP/Hostname)
    7. Default for "Port" if provided
    8. Default for "appUser" if provided
    9. Default for "appPass" if provided
    10. Default for "Interval" if provided
  9. Registration service creates a new record in the "AppSpecs" table for each set of application specific field values provided.

Application Configuration

Once an application is registered with the Tribe it must be configured to function correctly with values specifying how to interact with the remote data source. After configuration is complete the application is then activated (With the click of a checkbox).

  1. Application ManagerAn application manager is any tribe member with the "Manage Apps" privilege. logs into the Tribe.
  2. Application Manager brings up the "Application Management" screen.
  3. Application Management screen presents a list of registered applications and their "Active" status.
    1. Application name is a link to an "Application Detailed Information" screen.
  4. Application Manager clicks link for newly added application.
  5. Fautore builds "Application Detailed Information" screen
    1. Standard fields stored by the tribe are selected from the "Apps" table for the application.
    2. Application specific data descriptors are selected from "AppSpecs"
    3. Any values associated with the application data descriptors are selected from the "AppSpecData" table.
    4. The page is built using the "Apps" data as default for the standard form fields, the "AppSpecs" data to construct the form fields for the application specific data and the data pulled from "AppSpecsData" as the default values for the application specific fields.
  6. Application Manager fills in any missing data and saves the form.
  7. The Application Manager is returned to the "Application Management" screen
  8. Application Manager clicks the "Active" checkbox to activate the application for tribe use
  9. Fautore verifies the parameters of the application access systems only within the Fautore Operational Domain (FOD).
    1. If the "Computer" value for the application is a FQDN the domain name portion must match that of the Tribe FQDN or be "localhost"
    2. If the "Computer" value for the application is an IP address it must fall within the Ethernet IP broadcast mapping for the local LAN.
  10. The application is marked as "active" with a successful FOD verification or an appropriate error is present otherwise.

Application Use

This section is provided for context only. Exact steps for mapping applications to tribe members and activities are yet to be determined.

  1. Coterie Chief selects from active list of applications to enable them for use in their individual Coterie.
  2. Any Tribe member with sufficient privilege for creating instructions accesses the "Instruction Definition" screen.
  3. The "Data Source" section of the screen present fields listing Tribe/Coterie Members, Applications, "RegEx" filter defs for "Summary Content" and "Detail Content," and a "Data Type" pull down that would list values such as "Text," "Images," "Sound" and "Video."
  4. The "Data Destination" section of the screen present fields listing Tribe/Coterie Members, Applications, "RegEx" filter defs for "Summary Content" and "Detail Content," and a "Data Type" pull down that would list values such as "Text," "Images," "Sound" and "Video."
  5. Tribe Member selects an application from the source dropdown
  6. Tribe member selects any additional criteria to narrow down the source trigger.
  7. Tribe member selects an application from the destinations dropdown.
  8. Tribe member select data types to send
  9. Tribe member save rule
  10. Any data placed into the staging area matching the terms of the "source" portion of the rule will be sent to the destination application.