Hi Dan,
Note that this is a hybrid solution between OData and DMF, because the logic app (or your code) will use OData to get the RecIds that will then be used to slice the exportation.
To filter your entity by RecId, the entity must have the underlining table RecId as a field, for example, to filter the Customers entity by RecId you must add the CustTable.RecId field to it.
So, maybe you choose to use other fields instead of the RecId (the AccountNum for example) so you don't need to alter your data entities, but that's up to you.
In my particular case I had to export inventory transactions, so we sliced by Item.
First we created a new data entity to accommodate all the fields we needed, then we added the following action to it:
[SysODataActionAttribute("AddItemRange", false)]
public static str addItemRange(
DMFDefinitionGroupName _definitionGroupId,
DMFEntityName _entityName,
str _items)
{
str queryStmt;
DMFDefinitionGroupEntity dmfDefGroupEntity = DMFDefinitionGroupEntity::find(_definitionGroupId, _entityName, true);
var queryData = dmfDefGroupEntity.QueryData;
if (!queryData)
{
queryData = DMFUtil::getDefaultQueryForEntity(dmfDefGroupEntity.Entity, dmfDefGroupEntity.DefinitionGroup);
}
if(queryData != connull())
{
Query query = new Query(queryData);
QueryBuildDataSource primaryDS = query.dataSourceNo(1);
queryStmt = primaryDS.toString();
QueryBuildRange range = SysQuery::findOrCreateRange(primaryDS, fieldNum(MyCustomEntity, ItemNumber));
range.value(_items);
if (query.getSQLStatement(true))
{
QueryRun qRun = new QueryRun(query);
queryData = qRun.pack();
ttsbegin;
dmfDefGroupEntity.QueryData = queryData;
dmfDefGroupEntity.write();
ttscommit;
queryStmt = primaryDS.toString();
}
}
return queryStmt;
}
OData actions are methods written in X and exposed by the OData framework, you just need to decorate it with the SysODataActionAttribute and the action will show on logic apps.
This particular action is a static method and could be part of any entity. Like if you have to filter different entities you don't need to add a method to each entity, just place the action in a more generic entity (i.e. DataManagementDefinitionGroupEntity) and receive the field name as a parameter.
This method receives the Data Project name, the Entity Name and a list of item numbers separated by comma.
Here is how our logic app worked:
- Declare a variable to hold the Data Project name
- Declare a variable to hold the Entity name
- Loop through the items entity to get all items we should export
- Concatenate the item numbers in a string separating them by comma
- Call the custom action mentioned above
- Call the ExportToPackage action from the DataManagementDefinitionGroupEntity
Here is the first link you should look at to learn more about logic apps. This is Microsoft official documentation on Logic Apps, no need for a deep dive, but it's a good place to start and get the overview: https://docs.microsoft.com/en-us/azure/logic-apps/
Once you get started look at the following link, this is an example on how to build file based integrations using logic apps: https://github.com/microsoft/Dynamics-AX-Integration/wiki/File-based-integration-using-Logic-Apps
By experience I would say that the best way to learn logic apps is by doing. Logic apps are really simple and user friendly.
If you have a complex solution, you better write your own code, but for complementary solutions like this I rather use logic apps. If you don't have trillions of calls they can be inexpensive. And if you don't have a complex process they can also be easy to maintain.
