Hello, We are working on an integration with one of our business partners using the BPA workflows offered by IFS Cloud (We are on 23R1). All the logic is in place and is working as intended, but the BPA fails for “large” datasets. We are using the REST Call Task to send a web request to our partner’s API. The request body/payload cannot be stored as a string because when there are many items, the requestBody would quickly exceed the 2000 character limit to be stored in the Oracle database as a string. If it were to be stored as a string, we would receive a persistence layer exception at the end of the workflow.Instead, we are storing it in a process variable called ‘requestBody’ as an object.The request body field of the REST Call Task requires a string, so we must convert the JSON object to a string using Camunda Spin: JSON(requestBody).toString() in the task.This works perfectly for “small“ payloads. However, even though I am not storing the “large” string, it still throws the same p
Hello, In a workflow projection (now called API) task, we have the below action options.Create (HTTP POST) Read (HTTP GET) Update (HTTP PATCH) Delete (HTTP DELETE) Call (API Methods)This is great for most use cases, but PATCH is not the only HTTP method for updating resources via web requests. In my particular case, I need to send a PUT request to one of the IFS APIs to update certain data. Is there a way to invoke the PUT method through a projection task? I know I can setup a service user, obtain a bearer token, and run a REST call, but I would rather not have all that additional overhead. Any and all advice would be appreciated. Thank you,Dylan
Hello, I have an event that is triggered upon the removal or change of a record in the ShopMaterialPurOrd LU. That is the Entity that stores pegging data between shop order material lines and purchase order lines. The idea behind this customization is to print a shop order pick list to the appropriate printer when material pegged to a shop order is received in on the Register Arrivals page. Receiving the pegged material reserves it to the shop order and removes the record (or changes the pegged qty field) in the SHOP_MATERIAL_PUR_ORDER view, which triggers the event. The workflow works great for receipt of a single line. When two or more arrival lines are received, the event is triggered the appropriate number of times, but it only passes the information from the first trigger for every following trigger. This can’t be intended behavior; is it a bug? Is it a limitation? Is there a workaround that doesn’t involve trying to find a different trigger? Any and all help would be greatly ap
Hi all, We are having some issues with part revisions and I can’t figure out the best way to tackle them. A little background on how we are using the software first (We are on IFS Cloud 22r2): We are using the engineering part navigator to build out the components that an assembly is comprised of. Once the assembly is complete, we use the Engineering Revision Transfer Actions page to transfer the assembly and its components. We use the ‘all level transfer’ so the entire product structure is transferred, including any new parts that were created for that assembly. We also have Remote Warehouse Assortments setup for service vans so they can be replenished with items when necessary. The items are moved from our main warehouse to the remote warehouses via a transport task which is automatically created because the remote warehouses are setup with the Automatically Refill Putaway Zones option. The all-level part transfer causes an issue with part revisions for items that already existed in
Hi all, We are having some issues with part revisions and I can’t figure out the best way to tackle them. A little background on how we are using the software first (We are on IFS Cloud 22r2): We are using the engineering part navigator to build out the components that an assembly is comprised of. Once the assembly is complete, we use the Engineering Revision Transfer Actions page to transfer the assembly and its components. We use the ‘all level transfer’ so the entire product structure is transferred, including any new parts that were created for that assembly. We also have Remote Warehouse Assortments setup for service vans so they can be replenished with items when necessary. The items are moved from our main warehouse to the remote warehouses via a transport task created by a scheduled database task, Refill All Putaway Zones. The all-level part transfer causes an issue with part revisions for items that already existed in inventory. Any part that existed in inventory prior to the
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
