When you first start using Mobius, you might wonder how you can import data into the repository. First of all, people often use the term “import” for ingesting data, but the correct term when working with Mobius is “archive.” In this post, we cover various ways to get data into the repository.
Mobius is different from many other content management systems where you login, store, edit, and view files. It is used to store large volumes of data for long periods of time. You can of course retrieve this information via browsing and searching. The data in Mobius is read only.
AdminCentral and Archive Creator are used to archive report data.
Before archiving any data into the Mobius repository, the data should be analyzed and understood to capture the right information, so that the data can be searched and retrieved quickly. The following subsections describe the setups for reports and topics that are needed to archive the files and capture the metadata from them.
The first way to organize the data is by specifying a document type. In Mobius, this is indicated with a Report ID.
This is particularly important in Mobius because Mobius doesn’t have the concept of folders. Mobius View allows the users to navigate by selecting reports and the date/time when the data was archived. The date/time of ingestion is indicated by a Report Version. The Report ID and Report Version (date/time) are displayed as folders inside of Mobius View. This is a usability convenience rather than actual folders.
Reports can be defined in AdminCentral. Login to AdminCentral as an administrator, select Report, and add a new report.
Unlike other content management systems, no metadata is defined for each report (type). Instead, any necessary metadata (topics) can be assigned to any of the reports via a Policy or Image List definition.
Topics are metadata in Mobius. They are declared independently of reports. Any topic can be assigned to a report in a policy or an image list.
To create topics, login to AdminCentral as an administrator and select the Topic node. There are three different types of Topics allowed in Mobius:
- The length can be 30 or 255.
- Number: Many different formats are supported. Examples are:
- 2 decimal places
- Thousands separator
- Date: Similar to number, many different formats are supported. Examples are:
There are three ways to process archival data in Mobius. They are:
- Policy Based Processing
- Image Based Processing
- Section Code Location Processing.
Section Code Location Processing was used in the legacy system and is no longer used for the newer customers. This feature is still provided to support customers that have upgraded from previous versions of Mobius. This blog skips this option.
Policy Based Processing
The purpose of a Policy is to extract metadata from the textual content and properties of files that are being ingested. Extracted metadata can be used to set Report IDs, Section IDs, and other metadata (Topics) for each file. Since metadata is extracted from textual content based on rules set in a policy, the content should be structured a certain way or have keywords for the policy to identify the data. Policies can process the following data types:
- LPFD reports:
- Can contain both text and resources such as graphics and front information.
- Used in IBM AFP, Xerox DJDE/Metacode, Adobe PostScrip, PDF, Hewlett-Packard PCL formats
- Image Index file
- Created by scanning applications.
- Text files
- CSV files
- XML files
AdminCental and Archive Creator can be used to create or edit Policies.
When a policy is created, a blank Edit Policy dialogue is opened. Import a sample document from the Edit Policy dialogue. The following screenshot is an example of a Policy for a report document.
There are different “windows” available at the bottom of the Policy Editor. These windows can be opened or closed by clicking on icons shown at the top of the application. For setting rules for textural content, the following windows are very useful to see the settings:
- Field Window: This window shows the rules for the selected areas in the content. The selected areas are outlined in the content area. Areas can be defined by keywords, relative to the keywords, and by its location.
- Group Window: This window shows mapping between the fields defined above and Topics. In this example, the field “EFF_YR” is mapped to the Topic “HM_EFF_YR.”
- Sample Window: This window shows the extracted values for the topics. For example, 2018 is extracted from the content and assigned to the Topic “HM_EFF_YR.”
There are a set of popup dialogues available inside of the Edit Policy application, and these popup dialogues guide you through the process of creating these rules for fields and groups. The full description of Policy Editor can be found in the Mobius online document (https://support.asg.com/mob/vnt/10_0/mobius_ag/policy_editor_field_references.htm?Highlight=policy%20editor).
Image Based Processing
Image Based Processing is normally used for binary data, which can be in any format (not just images), that cannot be processed through a Policy. Following is an example of an Image List file that is used by Image Based Processing.
The content above should be saved as a text file. A file extension is not important.
The first line, REPORT-ID, is a mandatory field that tells what report is used for each of the files listed in the Image List file.
FILE should point to the file in the file system. Note that the file must be accessible from the Mobius Repository, so unless these files are saved on the server where Mobius repository is installed, it should be a UNC path and the service account must have the permissions to access the files.
TYPE filename extension that identifies the type of application associated with the data FILE.
SECTION is the section ID for the file. There can be multiple sections in a file, but Image List doesn’t have an option to identify specific pages for different sections in a file whereas Policy can.
TOPC-ID is the ID of the topic and TOPIC-ITEM is the value of the topic.
Mechanics of Archiving
There are three different ways to archive files provided a Policy and Image List.
Archive Creator is a Java client with a user interface, and it is included in the Mobius server installation package. And the client can run on Windows only. The application provides the following options for archiving the files:
- Policy Based Processing
- Image Based Processing
- Section Code Location Processing
“acreate” is a command line tool, and it can only run on Windows. It can use Policy Based or Image Based processing.
The following is a sample command line to run the tool. This is to archive “report.rpt” file using Policy “PolicyA”. There are more options available for the tool.
- Invoke archive creation using the “Inventory” document server
- Authenticate “John Smith” with a password of “abcd”
- Create the archive from the “report.rpt” input file
- Use “PolicyA” to determine report section and indexing
- Force the Report ID to Rpt1 (even if there is a different value set by PolicyA.)
- Distribute the documents immediately after the archive is created if the distribution option is configured in Mobius. Distribution options are softcopy, online viewing, and hard copy.
The archive RESTful API has the following options:
- Archive files on the server file system.
- Embed the archive file inside of the JSON request.
- It can perform Policy Based or Image Based processing.
Following is a sample API call with embedded data in the request:
- POST method
- http(s)://<host name>:<port>/mobius/rest/repositories/<repo id>/documents
- Authorization-Repo: Basic <base64(repoName + “:” + userId + “:” + password)>
- Accept: application/vnd.asg-mobius-archive-write-status.v2+json
- Content-Type: multipart/mixed; TYPE=policy; boundary=boundaryString
- Authorization-Repo: Basic authentication that includes the encoded string for repository name, user ID, and password.
- Accept: A fixed string for the JSON body.
- Content-Type: A fixed string that tells the request has a JSON body, and the data is archived through a Policy.
Body: The text content is embedded in the request body.
- –boundString: The word “boundString” is a separator for the start and end of each part inside of the request. It is set in “Content-Type” in the header.
- The first “–boundString” is for the metadata.
- The second “–boundString” is for the content of the file.
- The first “Content-Type” tells Mobius that the metadata is in JSON format:
- The second “Content-Type” tells Mobius the report is plain text data
- The last two dashes (–) after “boundaryString” indicates it is the end of the part list
The RESTful API can be more handy as it can be called from any location without any additional applications, such as Archive Creator and acreate installed on the local machine.
We hope that you’ve learned the various ways to get data into the repository through reading this post. Find out more by putting an upcoming webinar on your calendar, or feel free to contact us. We’re happy to discuss Mobius and all other ECM topics.