Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

HTTP FrameWork 4.0.9.7

Just an FYI.

I installed this on an 'older site' in preparation of installing a new version of our webapp somestage soon. They are not quite ready yet so are still using an older webapp version that requires HTTP_Services. This was working fine before the HTTP Framework install. Not so much after....

I reconfigured the API Server Settings (especially the API Call Procedure and Entry Point Service) but was not having luck.

Long story short, here are my observations.
1. ServiceSetup Insert is obviously not deployed with the HTTP Framework but maybe should be? The older version on site was missing the ServiceModule stuff included in newer versions that is required HTTP_SERVICES .
2. HTTP_SERVICES is missing the GetRequestBody service since it has been converted to a proper service. Unfortunately this was pretty important since HTTP_LOGIN_SERVICES needs the "Response = Request@<29>" to pass in the actual auth details... I added that into my copy and all was good.

I dont know if it was intended to work another way but that worked for me.


Comments

    1. I checked the official RDK and it does have the SERVICE_SETUP insert. Not sure why it would be missing in your system. I suggest doing a search in SYSPROCS or SYSOBJ for SERVICE_SETUP. Perhaps it exists in an app you aren't inheriting.
    2. I don't recall GetRequestBody ever being a service. Here is the official list of services in that module. Upon further reflection, I think we wrote that custom for you.
  • Don,

    Excuse me while I finish eating my crow....

    Service_Setup did exist but was missing something you added early 2017. I assumed that meant there wasn't a updated version in the deploy. That did strike me as strange I admit. That wouldn't be the first time something like that has tripped me up and you had to lend a helping hand....
    I will have a look when I can next get on that site in SYSPROC/SYSOBJ (it requires 2FA and I'm not the keyholder) .

    Well that explains it. I ended up going to a site with the same old web version (that was working) to trace it through. That didn't have the 'new' HTTP_FRAMEWORK installed though (MCP stuff).
    There was no comments in HTTP_SERVICES to indicate that procedure had been added at any stage so I assumed it was original. Custom sounds about right. You probably wrote it for that website! I will learn one of these days! The good thing is we actually dont need it for our current deployments. We (institutional memory) just needs to remember it needs to be there onsite until we actualy deprecate that particular old web version.


  • Don, futher to this, is there a way for the Framework to serve BOTH API call procedure types?

    Basically our 'old' web application needs HTTP Services (which the client above still needs as we are not in a position to migrate all that functionaility at this point) but our 'new' web application (which is were ALL new work happens) uses Web Api.....
  • No, not out of the box. Everything is driven from the "API Call Procedure" setting in the HTTP Framework Setup UI.

    However, if you care to update some existing code I think you can implement this relatively easily. My suggestion is to create a local copy of HTTP_Services (if you haven't already done so), and then go to the GetAPICallProcedure service. This is the service that informs HTTP_MCP whether to expect Web APIs or HTTP Services. Instead of having it check the flag, have it check for the existence of your stored procedure. Use the GetFullEndPointURL service to get the URL and then parse out the endpoint to determine what the possible stored procedure names should be. Then, return the appropriate value (i.e., HTTP Service or Web API) based on which program you find.
  • OK.

    I had noticed that bit of code when I posed the question. I was pretty sure your answer was going to be something like that. I just didnt know how the 'Realm' setting came into play...if I could use that as some sort of 'profile selector' or not.

    Thanks for that. I will let the boss make the decision on what he wants to do considering this should be a temporary one-off :)
  • The Realm is something of a "namespace" for websites, or APIs in this case. If you changed the realm on a per-site basis then you could also use that to determine how things should work. That is, it's just another flag that doesn't do anything within the HTTP Framework.
  • OK.

    That's fair enough then :)
Sign In or Register to comment.