sponsored links

Collapse

Announcement

Collapse
No announcement yet.

Vendor's Service Program Procedures Don't Work in My Service Program Procedure

Collapse
This topic is closed.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Vendor's Service Program Procedures Don't Work in My Service Program Procedure

    Yes, I'm sure that subject confused some of you. I don't know how else to sum up the issue I'm having. Here is the longer version:

    Background: We use a third-party IBM i SDK that translates and makes a REST API call. By translate, I mean that we load up a bunch of data structures and it uses a customized version of Scott Klement's HTTPAPI to make the request and receive the response back into the same and additional Data Structures. In the IBM i SDK, this vendor created a service program that contains an API call procedure that we call in an RPG program. I don't have their source code nor can I debug their service program. What I did was create a front end, of sorts, to their API call procedure which is where my service program and associated procedures come into play. It was an easy way for other Developers to make the API call without having to worry about what flags get set or what values are populated for various tasks. I do the heavy lifting for them and then call the vendor's API procedure.

    The Issue: Recently, the vendor upgraded their SDK which we installed on our Test box. We use Rocket's LMi software on our IBM i for change management so I checked out my service program and pushed it up through our various environments. This way, my service program was compiled using any new doodads and whatnots the third-party vendor may have added or changed. This is normally a straight forward process. I say normally because this time it isn't. If I use my service program, the data structures the vendor normally populates aren't getting populated. If I just use their API procedure in a totally separate program with made up data, it works fine. I am at a complete loss because I don't see anything in the joblog or any sort of program dump.

    I am still learning the ins and outs of service programs and activation groups so I really don't know what info to give you other than what I've given above. I'm looking for suggestions on what the issue might be or how to debug the issue. If you need more information, please let me know and I'll see what I can do to get you what you need. Thanks in advance for any help you may provide.
    Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest. - Isaac Asimov

  • #2
    Activation groups should have no impact here assuming that the "problem" data structures are being passed by you as parameters. Are you certain that their interface has not been changed in some other way that might impact this?

    Comment


    • #3
      What populates the data structures? Seems to me that DSes are just assigned the way any variables are, with logic like MyDS.MyField = (something). I can't imagine how incorporating a 3rd party tool would cause these to not get populated... seems to me there must be a bug or error somewhere in the code to make this fail.

      The most common reason I see on forums like this one for "empty data structures" is when people get confused about scoping. For example, they may have a local copy of a data structure, but are setting the fields in the global scope. As a result, the data is still blank in the local copy.

      Comment


      • #4
        Originally posted by Scott Klement View Post
        What populates the data structures? Seems to me that DSes are just assigned the way any variables are, with logic like MyDS.MyField = (something). I can't imagine how incorporating a 3rd party tool would cause these to not get populated... seems to me there must be a bug or error somewhere in the code to make this fail.

        The most common reason I see on forums like this one for "empty data structures" is when people get confused about scoping. For example, they may have a local copy of a data structure, but are setting the fields in the global scope. As a result, the data is still blank in the local copy.
        To be honest, I have no idea what populates the DSes. I'm guessing it's part of their processing that they do when translating from JSON to the DSes...which I can't see...and I assume it's as you said, they are moving values into their DS.

        The normal process is we populate 2 DSes(TaxH and TaxL) and pass 7 total DSes when we call their procedure. 5(TaxD, TaxA, TaxS, and TaxM) of them will be empty until after the call. After the call, the tax info fields in TaxH and TaxL are normally populated and TaxD, TaxA, TaxS, and TaxM are all populated with tax information where applicable. The weird thing is after the upgrade and within my service program, TaxH does contain tax information but none of the other Data Structures do which is not normal. It's almost like it gets so far and then stops for some reason. If I don't use my service program and just call their API procedure from an RPG program, TaxH, TaxL, TaxD, TaxA, TaxS, and TaxM are all populated after their procedure returns control. While debugging my service program, whose procedures are invoked from another program in the ERP system, I can see that TaxH and TaxL are populated and TaxD, TaxA, TaxS, and TaxM are empty prior to calling their API procedure. When their API procedure returns control, it stops at my breakpoint right after the call statement. I can see that TaxH is populated with tax information and the rest of the Data Structures are as I sent them: TaxL has the same info I passed in but no tax info and TaxD, TaxA, TaxS, and TaxM are all empty after control is returned.

        I appreciate the suggestions. I am at a loss for this one and I've never had this happen. I just get a little unsure when you introduce a change management system into the mix and then throw in the fact that it all runs from within an ERP system and why it makes a difference whether I use my service program procedures or not. Although, with the exception of my comment about whether I use my service program procedures, it's been that way from the beginning and this is the first time I've had this issue. I'll keep digging to see what I can figure out.
        Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest. - Isaac Asimov

        Comment


        • #5
          If you have any reason to think that the CM system is contributing to the problem why not build the programs by hand? Hard to believe that there is a difference though.

          The only thing I can think of is that you have a component that already binds to the old version of their service programs or something.

          Have you contacted the vendor to see if they have any ideas?

          Comment


          • #6
            Originally posted by JonBoy View Post
            If you have any reason to think that the CM system is contributing to the problem why not build the programs by hand? Hard to believe that there is a difference though.

            The only thing I can think of is that you have a component that already binds to the old version of their service programs or something.

            Have you contacted the vendor to see if they have any ideas?
            That is a good suggestion about building it by hand and outside of the Change Management system. We aren't allowed to compile anything outside of the CM system that will eventually make it into Production but it would be a good test to rule it out. We do have our own libraries and can compile and such outside of the CM system but there would be some tweaking required so that I don't interfere with the existing service program that's checked into the CM system.

            I did contact the vendor but we are on a standard support plan so it takes them a couple days to really provide any sort of answer. Since it is our homegrown software that communicates with their API procedure, they may not be willing to offer much help. We'll see what they say.

            Thank you for the reply and suggestions.
            Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest. - Isaac Asimov

            Comment


            • #7
              Originally posted by JonBoy View Post
              Activation groups should have no impact here assuming that the "problem" data structures are being passed by you as parameters. Are you certain that their interface has not been changed in some other way that might impact this?
              I didn't think Activation groups should have an impact but then as I mentioned, I am still learning even after 20+ years. I don't think the interface has changed because everything works fine when I call their procedure from within an RPG program but doesn't when calling it via my service program procedure. However, I am only making an assumption. I opened a ticket last Thursday asking for release notes so I knew what changed and am still waiting. I know they changed a file because prior to recompiling my service program in our Change Management system, I got a level check on one of their files but that's all I know at this point.

              Honestly, I would like to get rid of their SDK entirely and just use HTTPAPI and YAJL so this wouldn't be an issue but it is so embedded in our ERP system, it would require the same amount of testing as when we initially implemented it. I also don't think I could go to those in power and say that I want to rewrite it just because. Although, that was part of the reason I created my service program as a front end so that if we wanted to change, it wouldn't be terribly difficult.

              Thanks for the reply.
              Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest. - Isaac Asimov

              Comment


              • #8
                As Scott noted - the main cause of "disappearing" data in subprocedures is that you have local and global copies of the DS and the local copies are being populated and then "disappear".

                Hopefully rebuilding the program will give you some hints.

                Comment


                • #9
                  Thanks to another Developer that was looking into the same issue, the answer is that the vendor added a field to one of the data structures that apparently controls what is returned. I still have not received any release notes from the vendor so I have no idea what this new field is or what else was changed. Just for clarification, the reason the vendor's API call procedure worked in my test RPG program but not in my service program is because I took a copy of their example program and modified. It looked the same to me and I didn't notice any comments about changes or newer source dates. I missed the fact that there was a new field.

                  This upgrade out of the blue, not being sure up until the last second what version you're going to get when installing on a Production box, and missing release notes is pretty much the norm for this vendor. Normally, the changes are mainly behind the scenes and don't seem to affect how my service program behaves...until now. Sorry, that was a bit of me venting my frustration and has no bearing on the topic of this post.

                  Thanks to everyone who offered suggestions and replied. I apologize for wasting your time for something that turned out to be an issue with the vendor's SDK.
                  Last edited by thebkline; 1 week ago. Reason: Added clarification on why it worked in RPG program but not Service Program
                  Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest. - Isaac Asimov

                  Comment

                  sponsored links

                  Collapse

                  Working...
                  X