Topic
  • 31 replies
  • Latest Post - ‏2013-12-18T21:05:34Z by markevans
kennetheld
kennetheld
38 Posts

Pinned topic EGL Wrapper Call

‏2013-12-03T20:37:20Z |

I am hoping someone can send me a sample of a SIMPLE native JAVA call to a basic EGL generated wrapper.  I know in it's simpliest terms it creates the call program with parm1 as int and parm2 as string.  If someone could reply with the least of a program that you would use to call such and EGL program and include some simple explanation I would be SOOOO grateful.  I am very new to both EGL and JAVA and really appreciate the help.  Thanks.

  • markevans
    markevans
    2815 Posts

    Re: EGL Wrapper Call

    ‏2013-12-03T21:36:18Z  

    Hi,

     

    here is a sample project that you can import (using import->General->existing project into workspace->archive file

    In it is

    - an EGL program named hellopgm which takes two parms (strings).

    - a native Java class (main class) named startMe that invokes the HellopgmWrapper class that was generated and sets/gets the parm values

    - the .eglbld file with a linkage table and correct build descriptors to generate the wrapper.

    Hope this helps.

     

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-03T21:55:30Z  
    Mark, I am not seeing the attachment. Can you resend the attachment? Thanks so much. this sounds exactly what I am looking for.
  • markevans
    markevans
    2815 Posts

    Re: EGL Wrapper Call

    ‏2013-12-03T22:04:23Z  
    Mark, I am not seeing the attachment. Can you resend the attachment? Thanks so much. this sounds exactly what I am looking for.

    I see in the other post you were able to see the attachment.

    Also, FYI...it was exported using RBD V8.5.1.1.  If you import into RBD V9, it might do a migration which is fine to let it do it.

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-03T22:36:49Z  
    • markevans
    • ‏2013-12-03T22:04:23Z

    I see in the other post you were able to see the attachment.

    Also, FYI...it was exported using RBD V8.5.1.1.  If you import into RBD V9, it might do a migration which is fine to let it do it.

    Mark,

     

    One other email and hopefully I will not bug you any more.  Once I get the project imported should I just do a generate and compile your native JAVA code?  Will there be any tricks you can think of to get things compiled and runable?  Thanks again for all your help.

  • markevans
    markevans
    2815 Posts

    Re: EGL Wrapper Call

    ‏2013-12-03T23:15:40Z  

    Mark,

     

    One other email and hopefully I will not bug you any more.  Once I get the project imported should I just do a generate and compile your native JAVA code?  Will there be any tricks you can think of to get things compiled and runable?  Thanks again for all your help.

    First, can we keep the posts in the same forum entry.  Seems like they are bouncing back and forth between this one and the other one you started.   Let's use this one just to make it simpler.

    What I sent you was a Java project.   It contains the native Java class and the egl source which was generated into Java.  

    Within the workbench, all you should have to do after importing the project is select the StartMe class and then from the context menu, choose "Run as-> Java Application".  The compiled/generated classes are already in it. 

    Outside the workbench, deployment has many meanings.   But the example I sent you is just a normal Java application. 

    So, one way is to export the project as a jar file and then put that jar file in the CLASSPATH and also put the fda7.jar in the CLASSPATH as well.  The fda7.jar can be copied out of the install directories (see the location if you hover over this file in the workbench).   

    There are some instructions in the EGL InfoCenter in the section entitled "Deploying to a non-JEE environment"

    http://pic.dhe.ibm.com/infocenter/rbdhelp/v8r5m0/topic/com.ibm.egl.gg.doc/topics/gegl_core_container_gennonj2ee.html

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-03T23:37:05Z  

    Thanks Mark.  Sorry for bouncing between topics.  And thank you so much for all your help.  

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-05T14:58:40Z  
    • markevans
    • ‏2013-12-03T23:15:40Z

    First, can we keep the posts in the same forum entry.  Seems like they are bouncing back and forth between this one and the other one you started.   Let's use this one just to make it simpler.

    What I sent you was a Java project.   It contains the native Java class and the egl source which was generated into Java.  

    Within the workbench, all you should have to do after importing the project is select the StartMe class and then from the context menu, choose "Run as-> Java Application".  The compiled/generated classes are already in it. 

    Outside the workbench, deployment has many meanings.   But the example I sent you is just a normal Java application. 

    So, one way is to export the project as a jar file and then put that jar file in the CLASSPATH and also put the fda7.jar in the CLASSPATH as well.  The fda7.jar can be copied out of the install directories (see the location if you hover over this file in the workbench).   

    There are some instructions in the EGL InfoCenter in the section entitled "Deploying to a non-JEE environment"

    http://pic.dhe.ibm.com/infocenter/rbdhelp/v8r5m0/topic/com.ibm.egl.gg.doc/topics/gegl_core_container_gennonj2ee.html

    Mark,

    Just to understand things a little better I am went through the steps using your project as a guide and have created my own wrapper project.  I have also played with adding another parm as a integer,  Finally, I have added a small record to my EGL program and take one of the incoming parms and execute an additional function which   reads a Warehouse record and returns the description of the Warehouse.  While I am currently passing only a description back how easy would it be to pass back the entire record/resultset and how would I define that on the paramters statement within EGL?  

    Thanks for your help.  

  • markevans
    markevans
    2815 Posts

    Re: EGL Wrapper Call

    ‏2013-12-05T17:48:05Z  

    Mark,

    Just to understand things a little better I am went through the steps using your project as a guide and have created my own wrapper project.  I have also played with adding another parm as a integer,  Finally, I have added a small record to my EGL program and take one of the incoming parms and execute an additional function which   reads a Warehouse record and returns the description of the Warehouse.  While I am currently passing only a description back how easy would it be to pass back the entire record/resultset and how would I define that on the paramters statement within EGL?  

    Thanks for your help.  

    I have attached an updated project where I added a record to the "hellopgm" and I pass data from the native Java and then receive data back and display it.   You may need to delete the project you have in the workspace and replace it with this or create another workspace.

    Also, there is a pretty decent set of info in the helps related to how to deal with the various datatypes/record types used with the java wrappers.   It can be found at the following link in the EGL Info Center:

    http://pic.dhe.ibm.com/infocenter/rbdhelp/v8r5m0/topic/com.ibm.egl.gg.doc/topics/gegl_java_javawrapperclasses.html

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-05T19:55:06Z  
    • markevans
    • ‏2013-12-05T17:48:05Z

    I have attached an updated project where I added a record to the "hellopgm" and I pass data from the native Java and then receive data back and display it.   You may need to delete the project you have in the workspace and replace it with this or create another workspace.

    Also, there is a pretty decent set of info in the helps related to how to deal with the various datatypes/record types used with the java wrappers.   It can be found at the following link in the EGL Info Center:

    http://pic.dhe.ibm.com/infocenter/rbdhelp/v8r5m0/topic/com.ibm.egl.gg.doc/topics/gegl_java_javawrapperclasses.html

    Mark,

    Thanks SO much for your help.  You have really saved the day.  

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-06T00:19:43Z  
    • markevans
    • ‏2013-12-05T17:48:05Z

    I have attached an updated project where I added a record to the "hellopgm" and I pass data from the native Java and then receive data back and display it.   You may need to delete the project you have in the workspace and replace it with this or create another workspace.

    Also, there is a pretty decent set of info in the helps related to how to deal with the various datatypes/record types used with the java wrappers.   It can be found at the following link in the EGL Info Center:

    http://pic.dhe.ibm.com/infocenter/rbdhelp/v8r5m0/topic/com.ibm.egl.gg.doc/topics/gegl_java_javawrapperclasses.html

    Mark,

    I know you are bound to be tired of hearing from me.  I think I only have one more step to finalize the full circle of what I have been trying to accomplish.  Basically we use a 3rd party product called MRC for much of our Web Facing.  This product allows you to call out to stored procedures, RPG/Cobol programs and native JAVA code.  It forces you to specify the Class and Method when calling Java code.  If I pull out the source and compile the individual Startme.java app would I most likely only have to have the created JAR from EGL in the classpath for everything else to be found?  

     

    Startme will domino through the whole project as you well know.  I was just unsure as to whether I would need to make any other references other than having the EGL JAR in the class path.  Thanks, and I hope I am being clear.  

    MRC program is calling Startme.java which calls the wrapper which calls the EGL code and returns.  

  • markevans
    markevans
    2815 Posts

    Re: EGL Wrapper Call

    ‏2013-12-06T13:30:28Z  

    Mark,

    I know you are bound to be tired of hearing from me.  I think I only have one more step to finalize the full circle of what I have been trying to accomplish.  Basically we use a 3rd party product called MRC for much of our Web Facing.  This product allows you to call out to stored procedures, RPG/Cobol programs and native JAVA code.  It forces you to specify the Class and Method when calling Java code.  If I pull out the source and compile the individual Startme.java app would I most likely only have to have the created JAR from EGL in the classpath for everything else to be found?  

     

    Startme will domino through the whole project as you well know.  I was just unsure as to whether I would need to make any other references other than having the EGL JAR in the class path.  Thanks, and I hope I am being clear.  

    MRC program is calling Startme.java which calls the wrapper which calls the EGL code and returns.  

    Hi,

    You will need all the generated classes as well as the fda7.jar (the EGL Java Runtime).  The generated classes can be exported into a Jar file as part of the whole project including Startme.  (select the project and choose Export->Java->Jar file (or something like that).   This Jar file would need to be on the CLASSPATH.   The fda7.jar needs to be listed on the CLASSPATH as well.   The easiest way to "find" it is to hover over its name in the RBD Project Explorer and it will popup the location.

    That is all I can think of not knowing anything about MRC.

    take care.

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-09T15:41:53Z  
    • markevans
    • ‏2013-12-06T13:30:28Z

    Hi,

    You will need all the generated classes as well as the fda7.jar (the EGL Java Runtime).  The generated classes can be exported into a Jar file as part of the whole project including Startme.  (select the project and choose Export->Java->Jar file (or something like that).   This Jar file would need to be on the CLASSPATH.   The fda7.jar needs to be listed on the CLASSPATH as well.   The easiest way to "find" it is to hover over its name in the RBD Project Explorer and it will popup the location.

    That is all I can think of not knowing anything about MRC.

    take care.

    Mark,

    I wanted to see if you could possibly shed any light on this error.  When I create a runable JAR file eglwrapper.jar and process manually it works.  When I call it from within my MRC application it calls and links fine but gets the following EGL errors when trying to connect to the iSeries database.  

    egl.core.InvocationException: EGL0150E An error occurred calling the hellopgm program. Error: EGL0509E Cannot connect to the default database. The name of the default database was not specified.
    EGL0002I The error occurred in hellopgm processing the WHRead function.
    EGL0001I The error occurred in hellopgmWrapper.

    While I know you are not familiar with MRC I thought you might be able to shed some light on the following.  I am wondering if the JT400.JAR within MRC might be different from the JT400.JAR EGL was created with???  Maybe some other class file or something missing that EGL needs??  

    Thanks for any help you can provide.  

  • markevans
    markevans
    2815 Posts

    Re: EGL Wrapper Call

    ‏2013-12-09T15:52:29Z  

    Mark,

    I wanted to see if you could possibly shed any light on this error.  When I create a runable JAR file eglwrapper.jar and process manually it works.  When I call it from within my MRC application it calls and links fine but gets the following EGL errors when trying to connect to the iSeries database.  

    egl.core.InvocationException: EGL0150E An error occurred calling the hellopgm program. Error: EGL0509E Cannot connect to the default database. The name of the default database was not specified.
    EGL0002I The error occurred in hellopgm processing the WHRead function.
    EGL0001I The error occurred in hellopgmWrapper.

    While I know you are not familiar with MRC I thought you might be able to shed some light on the following.  I am wondering if the JT400.JAR within MRC might be different from the JT400.JAR EGL was created with???  Maybe some other class file or something missing that EGL needs??  

    Thanks for any help you can provide.  

    Hi,

    One of the outputs of generation of the hellopgm is some EGL Java Runtime properties.    One of these properties is the connect info for the database (vgj.jdbc.default.database.<name>)

    I don't know if MRC is a web application or a non-Web application.

    For J2EE (web) based applications along with the EGL build Descriptor J2EE = yes, the properties are generated into the web.xml.  It also assumes the use of a datasource.

    For non-J2EE based applications along with the use of the EGL Build Descriptor J2EE=NO, the properties are generated into a file named rununit.properties.  This properties file needs to be in the CLASSPATH and is generated into the root of EGLGen/JavaSource.

     

    NOTE:  Both scenarios above assuming the EGL build Descriptor named genProperties is set to Global (the default if I remember right).

     

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-09T17:35:18Z  
    • markevans
    • ‏2013-12-09T15:52:29Z

    Hi,

    One of the outputs of generation of the hellopgm is some EGL Java Runtime properties.    One of these properties is the connect info for the database (vgj.jdbc.default.database.<name>)

    I don't know if MRC is a web application or a non-Web application.

    For J2EE (web) based applications along with the EGL build Descriptor J2EE = yes, the properties are generated into the web.xml.  It also assumes the use of a datasource.

    For non-J2EE based applications along with the use of the EGL Build Descriptor J2EE=NO, the properties are generated into a file named rununit.properties.  This properties file needs to be in the CLASSPATH and is generated into the root of EGLGen/JavaSource.

     

    NOTE:  Both scenarios above assuming the EGL build Descriptor named genProperties is set to Global (the default if I remember right).

     

    Mark,

    Thanks for your reply.  MRC is a web application, but I have a question.  The original hellopgm was set as J2EE = NO.  Since MRC is simply transferring control to Class Startme will it look in the WEB-INF folder or will it use the J2EE = NO setting and expect to find the RUNUNIT.PROPERTIES files with the info?

    Lastly, since this is EGL code failing but running from the MRC server would I need to create the same directory structure from the base package directory all the way to the RUNUNIT file?  In other words, the base package directory in testing under MRC is MRCCLEAN2.  However it is calling a JAR file created from the EGL project and the path there to the RUNUNIT is WRAPPER\WRAPPERCREATION\EGLGEN\JAVASOURCE.  I am asking if I would need to create \EGLGEN\JAVASOURCE under MRCCLEAN2 to place the RUNUNIT.  Since the EGL was created as a J2EE = NO I assume I should follow this path because no WEB-INF would exist for that EGL app.  MRC would have a WEB-INF but I see no way for the EGL app to make it their.  

    I hope all this makes sense.  Let me know your thoughts.  Thanks.

  • markevans
    markevans
    2815 Posts

    Re: EGL Wrapper Call

    ‏2013-12-09T23:09:45Z  

    Mark,

    Thanks for your reply.  MRC is a web application, but I have a question.  The original hellopgm was set as J2EE = NO.  Since MRC is simply transferring control to Class Startme will it look in the WEB-INF folder or will it use the J2EE = NO setting and expect to find the RUNUNIT.PROPERTIES files with the info?

    Lastly, since this is EGL code failing but running from the MRC server would I need to create the same directory structure from the base package directory all the way to the RUNUNIT file?  In other words, the base package directory in testing under MRC is MRCCLEAN2.  However it is calling a JAR file created from the EGL project and the path there to the RUNUNIT is WRAPPER\WRAPPERCREATION\EGLGEN\JAVASOURCE.  I am asking if I would need to create \EGLGEN\JAVASOURCE under MRCCLEAN2 to place the RUNUNIT.  Since the EGL was created as a J2EE = NO I assume I should follow this path because no WEB-INF would exist for that EGL app.  MRC would have a WEB-INF but I see no way for the EGL app to make it their.  

    I hope all this makes sense.  Let me know your thoughts.  Thanks.

    Actually, I am not entirely sure if it handles it as a J2EE app or a non-J2EE app in this circumstance. 

    I would first try it with the rununit.properties.   The main thing is the rununit.properties needs to be found on the CLASSPATH..not necessarily a fixed location.   So, either the directory that holds it needs to be added... (try it) or thinking about it, if the rununit.properties was already part of the Jar, I would think it would have "seen" it, but it has been a long time since I tried this.

    Morten posted a similar item today regarding some linkage properties with java wrappers... where he used an extended definition since he was running WAS.

    One thing to try is also to set two other properties that produce trace output as this would let you see which usage triggers a trace.

    The properties are

    vgj.trace.type=-1 (negative 1)

    vgj.trace.device.option=0  (0=stdout, 1=stderr, 2=file)

     

    You could try adding these to the web.xml and seeing if it starts a trace.  If it does, then you know the EGL runtime is looking in the web.xml for properties.    This would be the web.xml for the base WAR project, not one for EGL as the EGL Jar is just a extra jar.

    Sorry, I cannot be more exact on this.   I just have not tried this in a long time.

     

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-09T23:28:58Z  
    • markevans
    • ‏2013-12-09T23:09:45Z

    Actually, I am not entirely sure if it handles it as a J2EE app or a non-J2EE app in this circumstance. 

    I would first try it with the rununit.properties.   The main thing is the rununit.properties needs to be found on the CLASSPATH..not necessarily a fixed location.   So, either the directory that holds it needs to be added... (try it) or thinking about it, if the rununit.properties was already part of the Jar, I would think it would have "seen" it, but it has been a long time since I tried this.

    Morten posted a similar item today regarding some linkage properties with java wrappers... where he used an extended definition since he was running WAS.

    One thing to try is also to set two other properties that produce trace output as this would let you see which usage triggers a trace.

    The properties are

    vgj.trace.type=-1 (negative 1)

    vgj.trace.device.option=0  (0=stdout, 1=stderr, 2=file)

     

    You could try adding these to the web.xml and seeing if it starts a trace.  If it does, then you know the EGL runtime is looking in the web.xml for properties.    This would be the web.xml for the base WAR project, not one for EGL as the EGL Jar is just a extra jar.

    Sorry, I cannot be more exact on this.   I just have not tried this in a long time.

     

    Mark,

    I actually did a SQLLIB.CONNECT within the EGL code and it worked.  I am going to work on getting the connection string passed from MRC to EGL and I should have it licked.  Will there be any gotha's or other problems I am not thinking about in doing it this way?

  • markevans
    markevans
    2815 Posts

    Re: EGL Wrapper Call

    ‏2013-12-10T13:06:49Z  

    Mark,

    I actually did a SQLLIB.CONNECT within the EGL code and it worked.  I am going to work on getting the connection string passed from MRC to EGL and I should have it licked.  Will there be any gotha's or other problems I am not thinking about in doing it this way?

    Glad you got it working.

    Assuming all access is a database, then no...can't think of any more problems.  File access also uses info from the rununit.properties, but you have not mentioned that so far.

    And assuming you are using a connection string (URL), then you are using J2EE=NO, so the only trick would be getting the rununit.properties "visible" if you want to go back to the implicit way of connecting.   That said, some people like to use SQLLIB.Connect since it also allows a userid/password to be specified.

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-10T14:35:03Z  
    • markevans
    • ‏2013-12-10T13:06:49Z

    Glad you got it working.

    Assuming all access is a database, then no...can't think of any more problems.  File access also uses info from the rununit.properties, but you have not mentioned that so far.

    And assuming you are using a connection string (URL), then you are using J2EE=NO, so the only trick would be getting the rununit.properties "visible" if you want to go back to the implicit way of connecting.   That said, some people like to use SQLLIB.Connect since it also allows a userid/password to be specified.

    Mark,

    What are you talking about when you differentiate between database access and file access?  In the repsonse previous to your last you mentioned me changing the web.xml file in the WAR.  This is a BASIC EGL project and is not running under web properties.  Would that still apply?  This wrapper project does not have a Web Content folder.  

    And as far as the rununit.properties file I have tried a number of things and nothing seems to work.  I am wondering if some of the EGL workings are lost when I call out to this JAR via MRC???

    The sqllib.connect seems to work for what I am currently doing.  If I wanted to make a call to an iSeries RPG program would that work or would I have another set of problems without getting the rununit problem resolved?  

    Let me know.  Thanks again for all your help.

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-10T17:48:51Z  
    • markevans
    • ‏2013-12-10T13:06:49Z

    Glad you got it working.

    Assuming all access is a database, then no...can't think of any more problems.  File access also uses info from the rununit.properties, but you have not mentioned that so far.

    And assuming you are using a connection string (URL), then you are using J2EE=NO, so the only trick would be getting the rununit.properties "visible" if you want to go back to the implicit way of connecting.   That said, some people like to use SQLLIB.Connect since it also allows a userid/password to be specified.

    Mark,

    One other topic where I would appreciate your input.  Do you know of a link or possibly have a project sample where EGL is being used to query a web service and parse the returned data?  Thanks.

  • markevans
    markevans
    2815 Posts

    Re: EGL Wrapper Call

    ‏2013-12-10T20:22:14Z  

    Mark,

    What are you talking about when you differentiate between database access and file access?  In the repsonse previous to your last you mentioned me changing the web.xml file in the WAR.  This is a BASIC EGL project and is not running under web properties.  Would that still apply?  This wrapper project does not have a Web Content folder.  

    And as far as the rununit.properties file I have tried a number of things and nothing seems to work.  I am wondering if some of the EGL workings are lost when I call out to this JAR via MRC???

    The sqllib.connect seems to work for what I am currently doing.  If I wanted to make a call to an iSeries RPG program would that work or would I have another set of problems without getting the rununit problem resolved?  

    Let me know.  Thanks again for all your help.

    Hi,

    A database call is something like DB2 through the JT400 JDBC drivers/DB2 drivers.   This is what you are doing since you are using sqllib.connect.   File access would be access to a serial file (txt, etc) in the servers file system.

    To answer your question on the web.xml.  In some circumstances, the EGL runtime detects that it is running in the context of a web application and based on this will only look in the web.xml. So even though the EGL code itself is not in a web project and the EGL code is just an additional Jar,, it still knows it is running in a J2EE server or context of a web application and looks at the current web.xml.  I don't know that this is the case here..but sometimes it is true.

    So.. maybe all this is a moot point..if the sqllib.connect is working and you can determine how to pass the connection info, we don't need to worry about the properties being found.

    On a call to the iSeries, you can set this up at generation time (server, library or library list, etc) so it is generated into the EGL classes.  In this case, no properties are needed.   If you want these attributes to be set and determined dynamically at runtime, that is also possible, but it does require a properties file to get the values (different than rununit.properties).  Again, this is the technique that Morten was using in his post yesterday.

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-12T15:29:32Z  
    • markevans
    • ‏2013-12-10T20:22:14Z

    Hi,

    A database call is something like DB2 through the JT400 JDBC drivers/DB2 drivers.   This is what you are doing since you are using sqllib.connect.   File access would be access to a serial file (txt, etc) in the servers file system.

    To answer your question on the web.xml.  In some circumstances, the EGL runtime detects that it is running in the context of a web application and based on this will only look in the web.xml. So even though the EGL code itself is not in a web project and the EGL code is just an additional Jar,, it still knows it is running in a J2EE server or context of a web application and looks at the current web.xml.  I don't know that this is the case here..but sometimes it is true.

    So.. maybe all this is a moot point..if the sqllib.connect is working and you can determine how to pass the connection info, we don't need to worry about the properties being found.

    On a call to the iSeries, you can set this up at generation time (server, library or library list, etc) so it is generated into the EGL classes.  In this case, no properties are needed.   If you want these attributes to be set and determined dynamically at runtime, that is also possible, but it does require a properties file to get the values (different than rununit.properties).  Again, this is the technique that Morten was using in his post yesterday.

    Mark,

    Do you have a sample project that consumes a public web service?  I have found a few links but have encountered problems with each.  If you have sample code or any direction I would really appreciate it.  I am just trying to understand the process to create an EGL process that will consume a web service and develop around it.  Thanks.

  • markevans
    markevans
    2815 Posts

    Re: EGL Wrapper Call

    ‏2013-12-12T21:24:02Z  

    Mark,

    One other topic where I would appreciate your input.  Do you know of a link or possibly have a project sample where EGL is being used to query a web service and parse the returned data?  Thanks.

    do you want to access the service from something generated as Java or from a RUI (i.e. from JavaScript)??

     

     

  • kennetheld
    kennetheld
    38 Posts

    Re: EGL Wrapper Call

    ‏2013-12-12T23:11:32Z  
    • markevans
    • ‏2013-12-12T21:24:02Z

    do you want to access the service from something generated as Java or from a RUI (i.e. from JavaScript)??

     

     

    java

     

    Thanks

  • PengFeiYu
    PengFeiYu
    29 Posts

    Re: EGL Wrapper Call

    ‏2013-12-13T06:15:11Z  

    java

     

    Thanks

    Hi,

    I attached a sample "ServiceSample.zip" which contains:

    • ServiceProvider: an EGL web project on Tomcat v6, it provides the EGL-generated SOAP service and REST service.
    • ServiceConsumer: an EGL general project targeting on Java, it provides the client that consumes the service, including:
      • Consume_EGLGenerated_SOAPService.egl: client that consumes the EGL-generated SOAP service.
      • Consume_EGLGenerated_RESTService.egl: client that consumes the EGL-generated REST service.
      • Consume_3rdParty_SOAPService.egl: client that consumes the 3rd party SOAP service.
      • Consume_3rdParty_RESTService.egl: client that consumes the 3rd party REST service.

    Also attached two tutorials of how to create/consume service step by step in EGL, please check it. For high level overview of EGL service, please refer to the info center:

    http://pic.dhe.ibm.com/infocenter/rbdhelp/v8r0m0/topic/com.ibm.egl.pg.doc/topics/pegl_core_service_part_cpt.html
    http://pic.dhe.ibm.com/infocenter/rbdhelp/v8r0m0/topic/com.ibm.egl.lr.doc/topics/regl_core_service_part.html

    Thanks & Regards