Skip to main content

In order to know what view we need to fetch information from in the past (IFS Appl 10 and backwards) we could always query the good old “Object connections” that has:

Now, since we only are allowed to fetch data from projections (starting with Cloud21R1 and upwards) - how do we know what projection to invoke depending on what object(s) a document is connected to?

Hi Andreas,

The simple answer is that you can't, at least not only with code and in a consistent manner.

The reason is that when we implemented the bulk of the forms in IEE to Aurena, we created projections to support the new pages. There are exceptions, but roughly each old IEE form now have one projection and one or more pages. There is a naming convention where, if we have a page called My Things, there is a MyThingsHandling projection that acts as the data source for the page. In each projection we expose one or more entities via entity sets, from where we can get the data.

By looking at the specification/metadata for each projection you can see what it exposes, but there is no easy way for you to know on beforehand.

Since I have some idea on what you might want to use this for, I know you will have a bit of a bumpy ride changing the way you get at "object" data.

I don't know to what extent you can query for information about what projections exposes what entities, because that would help you a bit.

Possibly you need to keep a list of good projections with good entity sets for common LUs, but that is also a bit shaky since they can be changed (we try to avoid changing things just like that, but for non-premium APIs/projections we make no promises.)

Any comments from @antonhornquist? I know you worked on the screens we use for working with projection grants. Could any of the projections you have created there be of some help here?

 


Thx for the reply, correct - in our Office addin we looked in the object connection basic data and then could automatically fetch information from that view and use the key definitions (depending on what object(s) the document itself was connected to.

But this means we have to pretty much store metadata elsewhere, and as you point out - ideally create our own projections (to guarantee that they will not change).

Do you know if there are upcoming changes in regards of Cloud21R2?


> Do you know if there are upcoming changes in regards of Cloud21R2?

I cannot think of any that would help with the above.

If I were you I would consider having some sort of default mapping between LUs and entitysets in projections, and let users have the option to override each one.

Possibly the new Query Designer (21R2 I think) might open up some new possibilities, but I don't know any details about that.
 


I don’t have an onscreen solution for you, however the AllProjections service endpoint has some of the information referenced above. Unlike the name, there are a couple restrictions on the list returned (Virtuals are excluded) however it does contain some of the mapping metadata.

Here’s a sample link to an internal environment: 
https://ifscloudr2bnt-lkp.rnd.ifsdevworld.com/main/ifsapplications/projection/v1/AllProjections.svc/Projections

You can also use the details from AllProjections to craft oData complient requests directly to the ODP server. We use this internally to populate some of the menus in the Workflow Designer.


Thanx, at least it narrows down the result by filtering on the logical unit name - but out of curiosity, when connecting to objects in Aurena client - how has it been handled there? I assume same challenge has been sorted there somehow (that is, identify what projection to invoke from the object connection basic data).


The mechanism for determining which Projection to invoke from within Aurena is a bit more involved.

The models (client, projection and entity) are transformed and stored within the database in an intermediate format, then translated again in some customized services generating Aurena specific metadata that contains the minimal linkage info.

I don’t recommend trying to decifer the Aurena metadata documents, but if you need metadata that isn’t exposed from an existing projection I would engage with @Nils Wendelöv 


Reply