We are using a custom event to make a Rest call. The call includes an header parameter that is a 64encoded value. We are able to put the complete header value in the event and save it. But, when the event runs, I get a “character string buffer too small” error. Any ideas?
Page 1 / 1
Hi @jhooperyan,
Below post might be helpful. Check the parameters/variables you are using with the scenarios described here.
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 add
dbms_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.
To provide more detail - we are using an event action to make a REST call. And this error started when I added security to the API being called, which added a header parameter. The error started when we added a header parameter that includes a security certificate. When I have no header parameters - this works. With the Header parameter - I get the error. Since this is all firing through a custom event, the variable error is happening somewhere in IFS code. I can save my parameter value in the Event Action, it’s just failing somewhere in the IFS internal code.
@jhooperyan
Try using place holders with the format <parameter>=<value> to define the Additional Header Parameters.
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:
The plsql_reset_sender_api has multiple methods. The ones that end with Empty_Body are for ‘get’ requests. where you are only submitting things in the URL. If you have a document, then you will want to use one of the other methods, but the concept is the same. Also, this snippet only has some of the parameters listed, there are many others for error_callback, header parameters, etc. You will then setup an address and a routing rule in connect that you configure for your endpoint. The header parameter you are adding will then be added to the endpoint, but the value for the certificate not be entered there. Instead you will use a placeholder variable that look like:
The additional header parameters are on the address screen. The code will then be in your custom event. In this example you could set header1 to Ocp-Apim-Subscription-Key and the value2 to your certificate (but remove the = in that case). Or what I would do is just replace that line in the additional header parameters screen with:
Ocp-Apim-Subscription-Key:{cert1}
Or something like that.
Keep in mind this is to model the solution like you have it, but you may want to look at the other setup options in the connect configuration to see if you can utilize the built in certificate capability. This way you are not putting your certificate in your code.
So - I traced the problem with the custom event, but what I found makes me think that the alternate PLSQL code version will run into the same problem. I’m wondering if anyone has enough detail knowledge to confirm.
In COMMAND_SYS.SEND_REST_MESSAGE, variable options_ at 2000 char is the first problem. But past that, it calls PLSQLAP_SERVER_API.Create_Application_Message___
PLSQLAP_SERVER_API.Create_Application_Message___ also has the 2000 char limit on options - which is based on table FNDCN_ADDRESS_LABEL_TAB (not a variable in the proc) - and column OPTIONS has a 2000 char limit
So root cause of my problem is the table definition
But - when I look at the code in PLSQL_REST_SENDER_API - it appears to also eventually pass through PLSQLAP_SERVER_API.Create_Application_Message___ - so I suspect if I set it up via code, I’m going to run into the exact same error message.
So now I’m trying to figure out if there is an alternate way to handle this certificate I need to use to connect to this API.