Recommended Suggestions
If Using Backups and Snapshots
Please be advised that if anyone wishes to use both the OnePlan_to_SQL_OneAnalytics and TakeOnePlanSnapshot strategies, we highly recommend that two separate integrations be made. Both strategies use the OData Table Name field, so if there are different tables that are to be snapshot than backed up, this can cause unnecessary tables to be created for the client.
Integrations Limitations
OnePlan_to_SQL_OneAnalytics – Full Sync Only
It’s essential to note that the OnePlan_to_SQL_OneAnalytics strategy operates as a full synchronization mechanism. Users do not have the option to selectively choose specific fields from each OData table to transfer over. The strategy mandates the inclusion of all fields associated with each OData table, ensuring a comprehensive synchronization process.
OData Tables with Paging Limitation
OData tables that employ paging mechanisms, especially those managing large volumes of data, may encounter limitations during the synchronization process. In some cases, a complete sync might not be achievable for such tables due to the inherent challenges posed by paging. This limitation is recognized within the current integration framework.
Snapshots not Available for all OData Tables
As of right now, the snapshot feature applies to all tables except for Capacity, ResPlan, Timesheets, and Teams.
Large Number of Plan Level Fields
Microsoft SQL Server has a limit on the amount of data that can be stored in a single row. In most cases, the number of plan level fields can fit in a row. If you have over 300 text fields in OnePlan, there is a possibility that saving the data into SQL Server will fail.
In that case, you will see this message in the job processing log:
“There are too many fields mapped for download, please remove some of them. Refer to the online help for more details.”
If you see this message, then please enable the Download only mapped plan level fields configuration setting and map the plan level fields you would like to download.
That the size of the data in the text field does not matter in this case. The issue is the number of the fields, not what is stored in them.
All tables related to Plans will be impacted by this field mapping.
The following fields that are considered “system” field will populate regardless of the mapping:
ID, Name, Created, Modified, Creator, Editor, Folder, ParentPlanId, ProcessStep, ProcessStepStart, ProcessStepIndex, Archived, PlanType, PlanId, PortfolioPriority, Summary_Milestone, State_Id, State_Value, Priority_Id, Priority_Value, Summary_Status, Summary_Complete, Summary_StartDate, Summary_EndDate, Summary_Effort, Summary_Duration, Summary_PercentDone, Summary_taskorder, Summary_WBS, VoteAmount