Data connections – InfoPath vs. MS portals
In this article I would like to take a focus on the problems of data connection when creating form elements in InfoPath 2013. A common scenario is use form (InfoPath example), which draws data from various sources. These data can be combined and appropriately filtered to whole system remained fast and to be as effective as possible. This is a fundamental challenge for every developer who works on the development of such solutions using standard, freely available tools.
Database SQL and InfoPath
InfoPath offers the possibility of defining a data connections which can be defined by SQL query, where you can choose which information is needed to download from the database, in which way you want to show them, or how these data should be interconnected. This is the first stumbling block. Many users believe that one data connection is one and only data source and mostly uses it, including keeping all the tables of the view. Data sources can be combined in the InfoPath product. It is only necessary to enter, which primary key will be used for creating necessary links between the data tables.
Individual data from the database can also been displayed or customized (the view) by SQL Query as a complement to the out of box InfoPath functionality (because not all can be set in GUI of InfoPath product). A typical example may be such as sorting of data from these secondary sources or the Join of tables or renaming the default names of the tables, or a calculated value. But there are more possibilities, these are only a basic examples of course…
REST and InfoPath
Another good source of data are often data from enterprise portals such as SharePoint. If it would be necessary to draw from the lists is not necessary to separately intend, it is possible to use a wizard to directly connect the required list, or a library (document of form). However, if (for example) there will be need to get data from a Microsoft Excel workbook that is stored in the library on the SharePoint portal, it is necessary to “touch” the more sophisticated solution, which is to use REST queries. These queries have the advantage that they can be quite extensively parameterized and thus uttering values into and from the Excel workbook using a single query (parameters into excel – final results from the excel (cell, object…)). This finds a practical use, for example, to deliver value to the Excel workbook, where there is possibility to make calculations with the value and then deliver a result back to the InfoPath form, when the Excel file can also be hosted on a SharePoint portal, so all the calculations should be online. However, this technique can be applied even if you were couched in Excel workbook, for example, the additional value that will complement values such as charts and the whole chart can be couched back to InfoPath as an object. This can add missing functionality to InfoPath as a standard in the manner you create graphs (till today only possibility of inserting static images).
SOAP web services
Finally, it is possible to use Web services that are part of most software solutions run on the principle of corporate portals, or parts thereof. Typical representatives of such applications as SharePoint, Project Server, CRM, Axapta and more. This way is also to obtain information about the currently logged on user and filter it according to other information which you provide within your form (ie it is possible for example to filter from a list of only those projects for which the logged-in user (which opened a new form) owner or project manager, or as specific trader for general business forms.