Skip to main content

Documenting Maps

When we are creating mappings in SCRIBE its important that we document those maps.  This is a two stage process.  First, we want to do an export of the map and save the JSON file into the source control system.  This way we have a back up copy of it and we can reuse the map if we need it again, similar to what you would do with a template.  The second reason is so others can have an understanding of the process.

In projects that I have worked on in the past I have taken more of a manual approach to creating the supporting documentation for my integration and migration mappings.  This can be time consuming to say the least.  During one of these exercises, I found the SCRIBE Documentation Tool.  I walk through the steps they outlined and it auto generated the documentation for me.  This has greatly speed up my work and gives me an spreadsheet that is easy to understand.

To create this documentation you will need a Google account as it uses Google Docs.  Here is a link to the detailed step by step process provided by SCRIBE.  Here is the high level process:

1) Allow API access to your SCRIBE Online organization.
2) Access the Documentation Tool by clicking this link. (Opens Google Spreadsheet).
3) Save a copy.  This is an important step as you create more then one of these, this way you don't over write a previous map documentation.  Also doing this will allow "SCRIBE" to appear in the menu next to "Help".
4) Click SCRIBE -> Documentation Solution and follow the prompts.
5) Once the process starts, depending on the number of mappings in the solution it can run quickly or slowly.  Just wait for it to finish.

When the process is finished you will see the following:

  • Org Details - This contains info about your org.
  • Solution Details - Details about the solution.
  • All tabs after the first 2 are the individual mappings in the solution.
    • The top section of each mapping tab will contain the high level map info.
    • After that section we start with the beginning of the mapping.  each block is highlighted, so it is easy to navigate between them.  under each block is the information contained in that block and the attributes used with what they are linked to or the conversion code we have written.
I hope this has helped you with documenting your data mappings.  Please check out the full documentation at SCRIBE's website.  Also SCRIBE provides the source code if you want to modify this tool for your specific needs.


Comments

Popular posts from this blog

Validating User Input In CRM Portals With JavaScript

When we are setting up CRM Portals to allow customers to update their information, open cases, fill out an applications, etc. We want to make sure that we are validating their input before it is committed to CRM.  This way we ensure that our data is clean and meaningful to us and the customer. CRM Portals already has a lot validation checks built into it. But, on occasion we need to add our own.  To do this we will use JavaScript to run the validation and also to output a message to the user to tell them there is an issue they need to fix. Before we can do any JavaScript, we need to check and see if we are using JavaScript on an Entity Form or Web Page.  This is because the JavaScript, while similar, will be different.  First, we will go over the JavaScript for Entity Forms.  Then, we will go over the JavaScript for Web Pages.  Finally, we will look at the notification JavaScript. Entity Form: if (window.jQuery) { (function ($) { if ...

Reusable Method To Get Record By Id

I have a handful of reusable code that I use when creating plugins or external process (i.e. Azure Functions) for working with DataVerse. The first one I am providing is Getting a Record By Id: 1: private static Entity GetFullRecord(string entityName, string primaryKey, Guid recordId, IOrganizationService service) 2: { 3: using (OrganizationServiceContext context = new OrganizationServiceContext(service)) 4: { 5: return (from e in context.CreateQuery(entityName) 6: where (Guid)e[primaryKey] == recordId 7: select e).Single(); 8: } 9: } entityName = The logical name of the entity primaryKey = The primary key field for the entity. If using late binding you can create this dynamically by doing: $"{target.LogicalName}id" recordId = Guid of the record to get service = Service to interact with DataVerse

Understanding Managed and Unmanaged Solutions in Dynamics 365

Dynamics 365, Microsoft's robust suite of business applications, boasts a myriad of features that can be customized to cater to the specific needs of any business. A vital concept to grasp when working with Dynamics 365 is the difference between managed and unmanaged solutions. This blog post aims to clarify these two types of solutions, providing a comprehensive analysis of the advantages and disadvantages of each. Unmanaged Solutions Unmanaged solutions act as a dynamic development environment, enabling direct alterations and additions to system components. They are often employed during the development and testing phase of a customization project but are equally effective when implemented in production instances, particularly for internal organizational operations. Pros of Unmanaged Solutions: Flexibility : Unmanaged solutions provide a high degree of adaptability, permitting developers to modify system components, introduce new elements, or discard those that are no longer nece...