Introduction

Within IFS, metadata for certain entity sets define a hierarchy of parent/child relationships with other entity sets, often identified as Reference entities. These hierarchies appear when browsing an operation (Import Wizard) and can be used in Get, Create, Update, Delete, and Query operations.

Background

Certain entity sets within IFS are related to each other in parent/child hierarchies. These relationships are defined in the metadata which IFS provides dynamically to Boomi through the connector. The IFS REST - Partner Connector comprehends and interprets these hierarchies, and when feasible, it presents them to the user in a significantly simplified format.

An example of these hierarchies might be the relationship between a customer order and the order lines of that order.  Here, a relationship exists between the parent order and the child array of order lines, based on the order number.  To retrieve the order lines, we use that relationship by, for example, getting the relevant customer order entity, and then getting the order lines for that found entity.

The URL which IFS uses to retrieve all the order lines for a particular order from IFS Cloud might be represented as –  
 

https://server.ifs.com:port/int/ifsapplications/projection/v1/CustomerOrderHandling.svc/CustomerOrderSet(OrderNo='BP10111')/OrderLinesArray

Here, CustomerOrderSet is the parent entity set and OrderLinesArray is a child entity set, and is actually an alias for the underlying entity set called Reference_CustomerOrderLine.  In the IFS REST - Partner Connector you can work with these two entity sets as if they were a single combined entity.  This combined entity is displayed with Boomi as CustomerOrderSet->OrderLinesArray.

Query Operation

When Importing the available objects from the CustomerOrderHandling projection on an IFS Cloud server as follows - 
 

we will see the list of available objects includes these relationships



When we select the CustomerOrderSet->OrderLinesArray object, the connector understands this actually represents two entity sets.  It will create a Response Profile and Field list dynamically for the OrderLinesArray entity, but also automatically add a field or fields to allow you to pass the necessary parameters to the parent CustomerOrderSet entity.  Here we see the OrderNo field, which in the example above we might set to BP10111.



In addition to setting the value of these dynamically created fields manually, they are also exposed as Dynamic Operation Properties on the step Configuration page.



Selecting Add Dynamic Operation Property will present a list of the available fields so that they can be set dynamically, for example through the use a profile elements, document properties, process properties etc..


 

Query Operations when no filter is specified

When a document is passed to a Query step, Boomi expects an element of this document to be used to specify a Filter in the Query operation.  Under most circumstances, you are passing a document to the Query operation to enable you to limit the responses of the query based on information from the inbound document.  However, in the above circumstance, we might want all items from OrderLinesArray for a specified OrderNo.  Here, the "filtering" is actually being performed on the parent object and we want OrderLinesArray unfiltered.  This particular behaviour , i.e. passing a non-blank document to a Query operation and then not specifying a filter, is not directly supported by Boomi and may throw an error.

This is easily worked around by firstly storing any elements you wish to use from an inbound document (e.g. OrderNo) into a Dynamic Process Property, then ensuring that you only pass a blank document to the Query operation, whilst then using the Dynamic Process Property to specify the Dynamic Operation Properties as mentioned above.

This behaviour is discussed in more detail in this separate KnowledgeBase article.

Get, Create, Update & Delete Operations

For Get, Create, Update & Delete operations, we once again select the combined object from the Import browser.  In this case though, a Request Profile is dynamically created which combines the required profile elements from both entities.  For the above example, the Request Profile will be created as follows



Here the element CustomerOrder_OrderNo will be used to specify the OrderNo for the CustomerOrder within the CustomerOrderSet entity, and the remaining parameters refer to each order line. 

In this example, the CustomerOrderSet entity set is made up of entities called CustomerOrder, so the naming of these objects is clear.  On occasion, you may find examples where the name of the entity, which is used to create these elements in the profile, is different to the name of the entity set, as seen in the URL.  For example, the entity set SerialReservationSet is made up of elements of type SerialReservationVirtual.  The element created in the profile would then begin SerialReservationVirtual_, not SerialReservation.  However, you can identify these parent elements in the profile through their naming structure entity_element.

In this example, the OrderNo is actually required as a parameter for both the parent CustomerOrder and its OrderLines, and so the same value should be set or Mapped to each of these parameters.