Ok, I’ve looked around everywhere, but cannot see that it is possible to set FormatSize? Has this been left out or is it coming in some service release/update?
Solved
Invoke action CreateDocument and set FormatSize
+8Best answer by Mathias Dahl
AndreasIsengaard wrote:
In order to reduce the risk that this occurs I see no other way than to develop own maintained projections, the APIs in the DB doesn’t seem to change a lot though so theoretically it shouldn’t be that much of a maintenance, and delivery through IFS Cloud Lifecycle seems to be an easy way of delivering and deploying.
That seems like a correct analysis and a pragmatic solution, for now. It's a pity that we have so few integration projections yet, but the sad truth is that they take time to develop and the primary focus has been to develop functionality for the end users. For a company like Addovation I think it makes sense to develop your own projections if you have a good way to deploy them for customers. But I think you should also request from us to add things you need in existing integration projections.
That being said, I think IFS will soon release a new feature that should solve at least some of these problems where we are lacking in the integration area...
+4Hi Andreas,
I also didn’t find a way to send the “Format” when creating and uploading a document ( CreateAndImportDocument.Svc). But you can update the record with Format value.
Before update
API Call (Patch)
After the call
+8Thanx for the input Ravi, but it feels more like a workaround then a proper solution - then there is no need for the integration projections I guess (since they are so limited).
I guess the best would be to develop our own projections in order to handle format size, revision support and status handling.
+4Hi Andreas,
I agree that the integration project is lacking of complete functionality in this case.
Btw, we almost never develop our own projections. We always advise customers to use an Integration Platform like Boomi, Snaplogic to communicate with IFS. Then let the Inegration Platform to call IFS standard Rest APIs to perform complete business logic of the integration. In that way we avoid modifications and hence reduce any maintenace effor in IFS end.
Best regards,
Ravi
+8When using IFS std / built-in projections we’ve seen that some of them change, and I’ve looked on Boomi (and the price) and believe that it mostly eases auth and transport layer and stuff - but fact remains, if IFS built-in projection changes → the integration will fail.
In order to reduce the risk that this occurs I see no other way than to develop own maintained projections, the APIs in the DB doesn’t seem to change a lot though so theoretically it shouldn’t be that much of a maintenance, and delivery through IFS Cloud Lifecycle seems to be an easy way of delivering and deploying.
+32AndreasIsengaard wrote:
In order to reduce the risk that this occurs I see no other way than to develop own maintained projections, the APIs in the DB doesn’t seem to change a lot though so theoretically it shouldn’t be that much of a maintenance, and delivery through IFS Cloud Lifecycle seems to be an easy way of delivering and deploying.
That seems like a correct analysis and a pragmatic solution, for now. It's a pity that we have so few integration projections yet, but the sad truth is that they take time to develop and the primary focus has been to develop functionality for the end users. For a company like Addovation I think it makes sense to develop your own projections if you have a good way to deploy them for customers. But I think you should also request from us to add things you need in existing integration projections.
That being said, I think IFS will soon release a new feature that should solve at least some of these problems where we are lacking in the integration area...
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.