[Infosistema DMM] Infosistema DMM - FAQ

Forge Component
(39)
Published on 12 Jul by Infosistema Solutions
39 votes
Published on 12 Jul by Infosistema Solutions

Q: After installation of the component from the Forge a message stating "There are files missing! Please make sure that IIS user as read and write permissions on the folder:" appears and nothing can be done with the tool.

A: This happens because Infosistema DMM needs to write access on a folder of the file system of the machine where it is installed to. To solve this error, check that the path in the site property "CustomSettingsPath" exists in the file system and that the IIS user has write privileges on it. The value can be changed in the settings page of the component. If this error is appearing on an OutSystems Cloud environment, then the value of the setting must be cleared and the checkbox "IsCloud" activated.

 

Q: I setup a new connection and received the message"The Connection was tested and failed the test but saved with success".

A: Infosistema DMM connects directly to the database using connection strings and standard .net IDBConnectionimplementations: System.Data.SqlClient if SQL Server orOracle.ManagedDataAccess.Client if Oracle. This error is fired when the produced connection string has some invalid property or when there are connectivity issues that prevent Infosistema DMM to connect to the database. To troubleshoot this issue, try to connect directly to the database in other application like SQL Server Management Studio or SQL Developer, using the exact same settings. Also, try to reach the database server from the machine whereInfosistema DMM is being executed from.

 

Q: I've followed the "Request CloudConnection" process but when I uploaded the encrypted connection via the"Set Cloud Connection" it failed with the error: "The Connection was tested and failed the test but saved with success".

A: More or less the same as the above but with more limited troubleshooting capability. Make sure that you've uploaded the encrypted connection to the same environment where you've made the request from, as it will only work there. If so, contact support so they can try to help discover what's causing the problem or provide a new connection.

 

Q: When I execute a migration I receive the following error: "The INSERT permission was denied on the object 'ossys_User', database 'xxx', schema 'xxx'."

A: This means that the connection you're using does not have the correct permissions to execute migrations. Namely, the INSERT permission on the OSSYS_USER Table. Database permissions must follow the documentation that can be found in the user manual.

 

Q: When I execute a migration I receive the following error: "Could not set IDENTITY_INSERT in table'[XXX].dbo.[OSUSR_xxx_xxxxxxx]'. Check if connection string has ALTER table permissions"

A: This means that the connection you're using does not have the correct permissions to execute migrations. Namely, the ALTER permission on some or all the OSUSR_* tables. Database permissions must follow the documentation that can be found in the user manual.

 

Q: When I execute a migration I receive the following error: "Not implemented mapper for: ossys_XXXXXXXX"

A: Infosistema DMM does not map all the OSSYStables, just the most common ones. So, you'll see this error if you have an entity that references an unmapped OSSYS table for some reason. ContactInfosistema Support so that we can add the missing mapper to the OSSYS table.

 

Q: When I execute a migration I receive the following error: "Cannot insert a duplicate key row in object 'dbo.OSUSR_XXX_XXXXXXXXX' with unique index 'OSIDX_OSUSR_XXX_XXXXXXXXX'. The duplicate key value is (XXX, XXX, XXX)."

A: This means that under the migration a unique constraint on the destination was raised as DMM tried to write a record that would cause a duplicate record to exist. This can be caused if the destination table already has information and the junction of the existing information with the one being imported has duplicated records where the unique index is concerned. Another way of this error to appear is if the source data is already non-consistent. i.e. the source has duplicated records. Finally, it can also be caused if one of the fields of the unique index is a Foreign Key to anOSSYS_ table that has not mapped records.

 

Q: Cannot perform migration operation under your current licence limits. You have 500 licensed MUs and need 626 MUs for this operation

A: Infosistema DMM has a subscription model associated and you've reached the limit of your current subscription. Either contact Infosistema support to increase your MUs limit with the purchase of anew subscription or split your migration in order to reduce the amount of needed MUs.

 

Q: How does OutSystems handle static entities? 

A: Static entities can be looked at as an enumerator on steroids. OutSystems handles them in three distinct tables:

  • OSSYS_Entity,     where the entity meta information is saved;
  • OSSYS_Entity_Record     where the real ids of the static entities are saved;
  • OSUSR_XXX_     the physical table where the values are written to.

The connection is then made between the Data_Id field from OSSYS_Entity_Record and the Id Field of the OSUSR_XXX_.

As this connection is managed in the eSpace itself it can produce some dramatic problems if you try to manually change some of the values directly in the database. 

 

Q: What is the Outsystems Metamodel?

A: OutSystems uses an under the hood surrogate model to abstract the entities underlying database structure.

This model is responsible for connecting the physical data tables to the application environment.

Pro Tip: If you wish to look at how they are connected, you can go to your database and poke around, look into the OSSYS_Entity and OSSYS_Entity_Attr table and there you'll find references to some familiar names of your entities.

 

Q: How are Foreign Keys Handled in OutSystemsMetadata?

A: When one entity has a relationship with another, their supporting physical tables will have Foreign Key constraints applied.

However, OutSystems will also keep track of this relation on their metadata information. If you look into the contents of the ossys_entity_attr, the column 'TYPE' will hold the internal datatype of that attribute.

When the attribute is an FK to another table, instead of a more readable value it will have something that follows the pattern: "bt*".

Extracting the values and will give you respectively the SS_KEY value of the corresponding space and the SS_KEY value of the corresponding Entity; thus allowing one to seamlessly navigate to the target entity of the relation.

 

Q: What is Infosistema DMM scrambling and anonymization?

A: Infosistema DMM Scrambling and Anonymizationis the common name of an engine that can be applied either at data at rest or during a migration scenario.

This engine is capable of changing the information in a non-reversible way and is used mostly to protect sensitive data. The engine has three features that can be used:

  • Anonymization - that simply generates random garbled text without any meaning;
  • Scrambling - that produces random data based on a pattern detection of the original data, it keeps the semantic value of the information as emails will look like emails, dates will look like dates and so on;
  • Ignoring - that will simply remove the information so it won't be accessible anymore.

 

Q: How can Infosistema DMM move data stored in separate DB catalogs?

A: In some OutSystems installation scenarios, the database catalog where entity information is placed is not the same one where OutSystems meta information is.

In these situations, Infosistema DMM needs to discover where the entity physical table is in order to produce its execution plan and commands.

The proper way to do it is looking into the OutSystems metamodel and that's exactly what InfosistemaDMM does.

After getting a pointer to the entity and respective eSpace in the OSSYS_ENTITY andOSSYS_ESPACE tables, the DBCatalog_Id column in the OSSYS_ESPACE table will have an FK to the OSSYS_DBCATALOG table.

In environments that use more than one catalog this table will tell us the name of the other catalog that should be used as a prefix in all subsequent queries or commands against the pretended entity.

 

Q: What are *OSUSR tables?

A: The OSUSR_* tables are the real entity datatables, their name is prefixed with a 3 letter code that is unique for each eSpace, so all entities from the same eSpace will be stored in tables with the same name prefix.

These are the least disruptive tables in terms of OutSytems operations and are those where manual edition will cause less impact as it's only customer data.

 

Q: What are OSLOG_* tables?

A: OSLOG* tables is where all the application logs are maintained.

The reason why there are so many OSLOG_* tables is because logs are kept partitioned in with a round-robin algorithm.

Replying just so this topic doesn't show up in the "unanswered" list.