Share via

Extensible MA and Data Source Systems that auto-generate anchor attributes

  • Article

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm

 

While developing an extMA for SharePoint Form library I ran into an interesting issue that I think will be worth sharing. The issue that I will describe would apply to any system that auto-generates an anchor attribute and if you are writing and extMA for it.

 

First a little bit of background

One of the functionalities of the extMA that I am developing was to create an InfoPath form in a SharePoint Form library for a person object in Metaverse (in MIIS talk, provision into SharePoint Form library). This would allow for integration of InfoPath and SharePoint with MIIS for purposes of workflow and data manipulation.  Since each form within the SharePoint library is auto-assigned a unique ID by the SharePoint I decided to use this ID as an anchor attribute for the form object. This implies that when provisioning to this connector space we need to use the following template (see MIIS developer guide for more details):

 

ManagementAgent = mventry.ConnectedMAs("sharepointlibV1.1")

Connectors = ManagementAgent.Connectors.Count

' Construct a temporary escaped distinguished name.

DN = ManagementAgent.EscapeDNComponent(System.Guid.NewGuid().ToString)

 

If 0 = Connectors Then

     csentry = ManagementAgent.Connectors.StartNewConnector("person")

    ' Assign the temporary escaped distinguished name to the DN property.

    csentry.DN = DN

    csentry.CommitNewConnector()

End If

 

The idea behind this code is to create a connector with temporary DN, since we really don’t know the real anchor value until the connector is exported.

So what I could not quite figure out at the beginning is how to change this temporary DN for the real formID. The issue was that I assumed that within the ExportEntry function of an extensibleMA I would only have read-only access to the csentry object, but after experimenting a bit it proved not to be true. Here is sample code that I used to export an entry:

 

Public Sub ExportEntry(ByVal modificationType As ModificationType, ByVal changedAttributes As String(), ByVal csentry As CSEntry) Implements IMAExtensibleCallExport.ExportEntry

        Select Case modificationType

            Case modificationType.Add

 

                generateFormFromTemplate(csentry, _

                                         diskFormFullPath, _

                                         templateForm, _

                                         sectionName)

                csentry("id").Value = UploadForm(docFolder, formName, diskFormFullPath)

 

In this code sample the heavy lifting is done by the generateFormFromTemplate function, which actually creates the xml document based on the values in the csentry and the template xml file that is provided as part of configuration. Next the form is uploaded to the SharePoint Form library via the function UploadForm, which in case of successful execution returns ID of the newly uploaded form.

The main point here is this line csentry("id").Value = UploadForm(docFolder, formName, diskFormFullPath). Csentry(“id”).value is the anchor attribute of the connector, and as you can see I am able to set it during the ExportEntry call, which ultimately replaces the temporarily generated DN for this connector.

So in conclusion, when developing an extMA for a system that auto-generates anchor attributes ensure to include code for replacing the temporary DN with the value assigned by the data system. This could be accomplished in the ExportEntry function.