Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: User role based customizable searches, where crawled documents may be evaluated against user roles or attributes during crawl time, are provided. Metadata retrieved from searched documents may also be evaluated against the user roles and/or attributes such that customized search results ranking documents based on their content beyond textual content may be provided.

Abstract: Data processing architecture where submitters can write data and/or metadata changes to a destination through an asynchronous interface. The architecture includes a ticketing system that issues a ticket (a unique identifier) to the submitter in response to receiving a changelist from the submitter. When the changes are successfully completed at the destination, the cached destination data can be re-downloaded to the submitter, and the changes cached in the submitter, discarded. Absent this capability, a user has to manually manage the cached changes and cached data. The architecture can be distributed in that multiple submitters can submit changelists. The destination provides data integrity by managing submissions to assist in ensuring data integrity across multiple submissions. Automatic changelist cleanup is provided on the submitter so that changelists do not impact performance, memory, and storage.

Abstract: Architecture that employs a journal assignment that can be created on demand when journal is created, and operates outside the business cycle. The assignment is routed to reviewers and approvers based on predefined company policy that users define. The assignment encloses a changelist of data changes created by the journal. The changelist is used for rendition and calculation for reviewers and approvers (in addition to the journal contributor) to view/verify and modify the data as if the data is already written into the model. At the time that other users access this model, the data is not present. At the end of the successful workflow chain the changelist is written into the model. If failed, the changelist will be used as that basis for correction or the user can discard the changelist.