I figured this out: The failed callback creates a background job with argument type ‘Normal Parameter’. As such, the callback procedure must contain the correct parameter names, which does not seem to be anywhere in the documentation. The correct format for the fail callback procedure is: PROCEDURE my_fail_callback(error_text_ IN VARCHAR2, app_message_id_ IN VARCHAR2)
You can query these values. The app_message_id_ is passed to your callback as a parameter. SELECT *FROM IFSAPP.MESSAGE_BODY a1WHERE a1.APPLICATION_MESSAGE_ID = app_message_id_ MESSAGE_TEXT - contains the bodyPARAMETERS - contains the parameters sent
Hi @jhooperyan, I understand now. You are exceeding the field length allowed for the header based on how the event processes rest calls. You will need to switch to PLSQL and code it in an anonymous block. The following is a snippet from the IFS technical documentation that you should take a look at for reference, but it is representative of how something like that would look:url := PLSQLAP_DOCUMENT_API.New_Document('url_params');PLSQLAP_DOCUMENT_API.Add_Attribute(url,'parameter1','/myResource');Query_params := PLSQLAP_DOCUMENT_API.New_Document('QUERY_PARAMETERS');PLSQLAP_DOCUMENT_API.Add_Attribute(Query_params,'value1', 'abc');PLSQLAP_DOCUMENT_API.Add_Attribute(Query_params,'value2', 'xyz');plsql_rest_sender_API.Call_Rest_EndPoint_Empty_Body2(rest_service_ =>'MY_REST_SERVICE',url_params_ => url,callback_func_ =>'callback_fn',http_method_ => 'GET',http_req_headers_ =>'Content-Type:application/json',query_parameters_ => Query_params);The plsql_reset_sender_api has mu
Hi @jhooperyan,The link provided by Radini is a good explanation of your issue. Specifically though you are getting a character string buffer too small, which means you are attempting to store a value within likely a varchar2 variable, either in the parameters of your API call or your declared variables. What I typically do when troubleshooting something like this is to adddbms_output.put_line(‘****’||variable);into your code and then you can search for the output in your debug window. Click on the Server Trace tab and search for **** to get to it quickly. You can also put something like length(variable) as well. Once you isolate which variable is too long you can. adjust your code to fix it.
There are load balancers, but no azure load balancers. I have a suspicion that there is possibly a 30 sec timeout or something like that in the load balancer that is closing the connection before the response is received.
If you have database access, you can look to see if that method exists in the oracle package: You can also look for it in: If it exists, then you probably have one of two issues:You don’t have permission to access that method → check your permission sets Your dictionary and security cache needs to be updated → refresh the server cache (it is in the same menu section above.If it does not exist, then you will need to put in an IFS request to request it be delivered. If it is not owned then it will need to be purchased.
There are two ways that I know of to set this up. Both approaches use the Object Connection Transformations located under: Application Base Setup > System Setup > Object Connection Transformations.The first way works when an existing relationship is already established in the system. Since you are going from PurchaseReceipt to PurchaseOrder, you may be able to get it to work by double clicking in the Transformation field and filling in the order_no as the only field. It would be a source of PurchaseRequest and a target of PurchaseOrder for a DocReferenceObject type service. You can set the other parameters per your requirements. Anything attached to the purchase requisition will then be available on the purchase order. The second way is by create a utility package and deploying it to the database. You can scroll through the other transformation methods you see in this screen to find an API to use as a template. You would need to have the rights to publish packages to the d
If the rowkey column already exists in the table then you may need to add a sys_guid() to any rows with a null value prior to activating the rowkey within IFS. Example:UPDATE table_nameSET ROWKEY = SYS_GUID();WHERE ROWKEY IS NULL; COMMIT; This has worked for us in situations where the rowkey was activated at one point, deactivated, and then an attempt to activate it again is done at a later point in time. It may also have something to do with DME being installed in the environment and a rowkey is not activated on a prerequisite table. Regardless, running this update prior to activating the rowkey in IFS worked.
I have seen this in a few circumstances including conflicts between the Base profile and Personal. The Personal profile will take precedence over the Base profile. There are multiple components in the profile that control the screen layout and only when one of those components exists in both the Base and Profile will there be a conflict. I have not found it practical to limit the user's ability to modify their personal profile in all cases so I have had to reconcile the profile issue. The best way I have found is to write a standard work instruction on how to do base profile edits. Different people do it differently using techniques including importing, pushing from one profile to the other, directly editing (not common), and switching to the base profile to make changes. This last approach works best. I have also seen a strange manifestation when the app owner is not assigned a base profile, but this does not impact the users. It just creates a very strange looking screen when m
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.