Questions
Here are the answers to the questions in this chapter.
| Miss Vector says... |
|
Hi, I'm Miss Vector, FME schoolteacher. I'll be here now and then to test you on your new FME Server knowledge. For now, answer me this: Which of these is not one of the three core capabilities of FME Server?
1. Automation 2. Real-Time 3. NoSQL Database 4. Self-Serve FME Server is many things - but it is not a NoSQL database! |
| Miss Vector says... |
|
I have an FME Server with two engines. Four users submit jobs at the same time. What happens?
1. Two jobs are processed. Two jobs are returned to their authors. 2. Two extra engines will fire up automatically to process all four jobs. 3. The four jobs will be processed simultaneously, sharing the two engines. 4. Two jobs are processed. The other two sit in a queue until an engine becomes free. Yes, the server core keeps a queue of jobs and submits them as engines become available. Extra engines will not fire up, even if you do have spare licenses, and jobs will never be ignored just because no engine is currently available. |
| Miss Vector says... |
|
If I wanted to find out about workspaces stored in a repository - for example I'm building a tool to catalogue my workspaces - what is the best way to do it?
1. Use the FME Server REST API 2. Scrape the contents of the Server repository page 3. Get a file listing from the repository folder 4. Connect to the FME Server database to query it directly The REST API is a quick, simple, and official method to query the workspace repositories. Querying the database directly is permissible, however, under no circumstances should you write into or update directly the contents of the database. |
| Miss Vector says... |
|
Which of these are good reasons for running engines on multiple operating systems at the same time? Pick all that apply.
1. A required format is only available on 32-bit or 64-bit, not both. 2. A required format is only available on Windows, or Linux, not both. 3. FME Desktop users author workspaces using a mix of Windows, Linux, and Mac platforms 4. You want to process heavy-scale jobs on a more powerful platform. Basically some formats are only available on certain platforms and so you may need to mix of operating systems to cover all your requirements. You may also want to redirect large-scale jobs to a more powerful platform. However, it doesn't matter what platform the workspace author used; their jobs will run on whatever system FME Server is based on. |
| Miss Vector says... |
|
If I create a database connection that has superuser permissions then it would bypass any permission checks the database would make for creating and dropping tables. So how do you think I might prevent a user misusing that capability?
1. Remove that user's permission to run that workspace on FME Server 2. Remove that user's permissions to access the entire repository that workspace resides in 3. Remove permission to access that particular database connection for that user's role 4. Remove from their role permission to manage database connections You know it can't be 1 or 2, because the user could simply create a new workspace in a different repository and use that connection. You could remove permission to manage connections (4) but that won't prevent access to ones already created. You should have the system administrator find that connection in the security page and remove from it any roles or users that should not have access. |
| Miss Vector says... |
|
Although simple, there is a major limitation to publishing data with a workspace. What do you think it is?
1. The data is only temporary and will be deleted once the workspace is run 2. The data is hidden within FME Server's system files and limited in its use 3. The data becomes available to anyone regardless of role and security settings 4. The workspace cannot be run using any other data than that published with it The limitation is that a dataset published in this way can only be referenced by its own workspace or workspaces run from the same repository. Even then there is no browse capability in the FME Server web interface; the source dataset parameter would need setting manually. Incidentally, none of the other answers are true: the data won't be deleted, it isn't open to anyone (unless they have specific access to this repository), and the workspace can be run using other data if required. |
| Miss Vector says... |
|
I copy a workspace into a resources folder using the upload tool. What then?
1. I can run it by browsing the resources, selecting the workspace, and clicking run 2. I can run it through the Manage > Workspaces menu tools 3. I can run it by calling it with the FMEServerJobSubmitter transformer in FME Desktop 4. I can't run it because it's not properly published to a repository Basically, if you don't publish the workspace properly, you aren't able to have Server run it. |
| Miss Vector says... |
|
Uploading an entire folder of files come with what restriction?
1. Folder upload only works on certain web browsers 2. Folder upload requires the folders to be zipped into a single file 3. Folder upload only works on Windows C: drive (not D:, E:, etc) 4. Folder upload requires FME Desktop to be installed on the computer being uploaded from Folder upload works in Chrome, but not in Firefox, Internet Explorer, or any other web browser. |
| Miss Vector says... |
|
So I can make my workspace read specific data from the resources folders - but how do I stop the end-user from being able to change that?
1. Remove their security permissions for the Job Submitter service 2. Remove their security permissions for the Resources folders 3. Make the source dataset parameter optional for that Reader 4. Delete the published parameter for that source dataset from the workspace Yes, in the Navigator window look for a published parameter that relates to the source dataset, and remove it. The option to change the dataset will then not be presented to the user. |