Plex 2E

Hello out there.

We are trying to rewrite our web front end in ASP.net / c#.net calling Plex RPG on IBM System i / Iseries / AS400 function for Data fetches / Saves / Validation.

It kind of works but is flaky:

About 1 in 10 or so fetches appears to fail to connect to the Iseries and the page is displaying empty data. This seems particularly (but not exclusively) common when the page is called for the first time for the session.

This also occurs for saves. Is there anything we can do to get round this connection failure?

In addition we have discovered that every time we make a call to Plex RPG functions from c# - i.e. for each request, a new Iseries job starts up and closes - this means we sometimes have to start up 3 new jobs for a save / fetch / validation request. This is causing severe performance problems.

Does anyone have any experience in this sort of environment so that we can run ASP / Plex in a more stateful fashion - i.e. maintain an Iseries connection for a session that is re-used for each call to the Iseries?

I have a issue number with CA - 20263510 01

Hi Mike,

We are doing something similar here. We took the approach of exposing our Plex RPG programs as web services that the .net programs call. We utilize the Web service wizard in WDSC to create the web service front end. It generates Java code for us which we deploy in Websphere. So far, performance has been acceptable. We have only used this for displaying data up to this point. We are just getting ready to start our first real business app (adding, changing, validating data) with this technique, so I'll be curious how it goes. Let me know if you would like more information about our approach.

Dean Eshleman,
Everence Financial

hi!

I am right now looking into exposing Plex RPG functions with web services using Websphere and would appreciate all information good and bad about using this method of work.

Hi Philip,

Do you need to know how to use the Webshpere wizard or do you already know how to do that? Maybe you know this already, but the Websphere wizard needs a PCML file that describes the parameter interface for the RPG program. Then, the wizard uses this PCML file to generate the Java front end which is deployed in WebSphere.

Normally, the PCML file is created via a option on the CRTBNDRPG command. We decided not to use this option since we weren't sure how to automate specifying this option as well as specify the PCML file location on the IFS. So, I created an abstract function in Plex that will generate the PCML file for you. This function allows us to specify the field names that we want in the PCML. We use the "DDL override NME" triple to specify the name we want.

Our web services are grouped based on what data library they are accessing as well as whether or not they update data. When I say grouped, I'm referring to the EAR file/Project they are put in. So far, we have 6 or 7 EAR files deployed with about 15 to 20 web services running. Our most recent issue was how to secure the web services that update data. We used the Apache security to only allow calls to these web services from the production .NET servers. This was done by IP address.

Let me know if you need more information.

Dean Eshleman,
Everence Financial

Philip_ wrote:

I am right now looking into exposing Plex RPG functions with web services using Websphere and would appreciate all information good and bad about using this method of work.

Hi Dean,

Thank you for all the information!
I have never used Websphere so that is all new to me. Anything around this is helpfull in my process to get the hang of it. I just started to read a little about and it´s growing slowly :)

Hey Mike,

Wow that is news, bet the office is glad now I introduced and drove the plex standard of interfaces (Field Lists), separate Validation, Save, and Fetch services for all new development since 2004 should make the migration cheaper, easier, faster to a new UI. God it was unpopular :vader: at the time! but the benefits will be enjoyed now. Can I ask why the move from websydian front end, they got some great stuff coming.

Wish I could be of help on the dispatcher issue but have a good feeling you will get a good result from CA on this issue as it will interest other AS400 sites with similar company strategies.

Regards to the workers, George

Unfortunately we found the Plex patterns you wrote quite a drawback George and we have had to spend quite a considerable amount of time unpicking them.

All the best

Hughesy

Well thats a great pity, what was wrong with them so I will not make the same mistakes again. Surelly it was at least more useful having the logic out of the UI?

Unpicking them? Why becuase it used global memory, or session data, or sent errors to websydian same page error handling. How can it be a draw back having the logic (bad or good) in separate functions, surely if the logic was in the websydian page generator and eventhandler as it was the case before you would have had NO reuse.

There will always be unpicking changing a complete arhitecture but your reply makes out that there was no postives at all just a mess which I would have to ask why on a public forum.'

Bad day at the office?

"All the best"
George Jeffcock

Hi George,

You have as they say "fallen for the bait"

Calm down dear.

Mike_Hughes wrote:

You have as they say "fallen for the bait"

I will have my sweet revenge Mr Hughes, you gave me a heart attack there. Love to all at Platform X

G'day Mike,

Have not done this in Plex before - but have deployed stateful web services from 2E.

You need to do some research into how to establish a stateful web service from asp.net - as by each connection does not retain information about prior connections and there is no persistent job on the iSeries that you get from an interactive session.

Just a did a quick search on persistent sessions and found the following link:

http://www.ibm.com/developerworks/webservices/library/ws-tip-stateful/index.html

Your asp.net application will then have to manage the persistent session information to be used on susequent calls.

HTH,

Darryl

Ah, so good to see you two old colleagues reunited.

Mike, as Darryl suggested you are going to have to do some plumbing work here. The good news is that there is no shortage of options as the other contributors have demonstrated. The missing piece which you should consider constructing is a small application server which can hold open the connection for each of the active web client calls. If you can implement this as some kind of pool of anonymous jobs, so much the better. But more likely you will need to reserve the conversation for each ASP.NET client and use session state to reconnect to your application server with each request.

I bet you hoped that it was going to be easier than this, right? Well, if you want a quick cheat, wrap the RPG program as a DB2 SQL Stored Procedure and use ODBC as the transport between windows and the iSeries. DB2 will manage a connection pool and should do an efficient job of invoking the program.

That might keep you going until you come up with a more sophisticated plan.

Cheers,

Matt

Hey Mat, ex colleague twice over, feel free to have a pop also if you want, open season here.

Tell Jez just fired off a mail to Rob Layzell to ask for progress report on the model API out of memory problem.

Cheers
George

Matt,

We were considering the 'dispatcher' type approach but trying to avoid it as it is a big unknown and no-one here really knows how to do it. More of a last resort really.

But your suggestion of wrappering the functions as stored procedure is very good - we will look into it.

cheers

Hey Matt,

Have you ever wrappered Plex functions as stored procedures? Did you have to re-write the functions so the parameter fields are all seperated into seperate Plex variables so that they are generated as seperate RPG parameters?

What approach would you take to the multi-occurance data structures that Plex uses for Blockfetches? I have researched a way of converting these to SQL result sets but I am a bit unsure if ASP will cope with packed decimals in the middle of a row.

Also, I am wondering if it is possible to have more than 1 result set if the Plex function has multiple multi-ocurrance data structures.

cheers

Mike

Mike,

Lots of activity on this topic, all very interesting.

With regard to wrapping a BlockFetch style function, the answer is no. SQL works with result sets rather than MOV's, so it's a non starter. What I have seen is a hybrid approach of wrapping "simple functions" which are typically for update or single fetch behaviour, and then using just SQL when it comes to the retrival of blocks of data. Using SQL for retrival is likely to be less expensive than running at BF function, but will be at the loss of reusing programs which you have already written.

Keep persuing the issue with CA Support, if you have a ticket then they have to look at it. Keep up the pressure until you can get the problem in front of someone who is familiar with the history of the product, and that might mean some work on your end to package it up so 1st/2nd level support can recreate the problem. As an aside, have you tried tuning the subsystem on the iSeries to make it as responsive as possible? I wonder if the failed calls are due to a lack of job processing resources or if it is in the network load and the Plex listener can't deal with a blizzard of connections and refuses the call.

There seems to be no single solution to the problem which you are up against, and I know you would prefer it to be as simple as possible. I think that the missing piece is an application server of some description. Whether you have to write that yourselves as a C# service which holds a pool of Plex connections or use something like Websphere or some other flavour of web services, as has been suggested in these threads, will depend on the skills and time that are available. If you look at other solutions out there, they all make use of this approach. For example on the iSeries there is the IWS/IAS or the more heavyweight Websphere servers, IIS has the ASP pool, and something else which you might be familiar with, Websydian Server, an application server written for the specific purpose of marshalling Plex calls over a stateless connection.

I have more questions than answers, I hope that you're making some progress towards a solution.

Matt

Thanks Matt for your suggestions.

I appreciate that the whole thing would be be quicker and simpler if we could rewrite the back end. Unfortunately our management will not consider this due to costs and time.

We are still investigating stored procedures - I found a bit of code to convert an RPG data structure to a result set. However, we have not got calls to stored procedures working yet and I dont think it is our preferred solution.

Websydian is out of the question - we are trying to move away from it.

We have limited knowledge of application servers - we do use Websphere here but our skillset is limited - maybe we need to buy in some outside help. I know nothing about object pools or IIS pools.

Still not getting any joy from CA.

Hey Matt,

Thanks for the Stored Procedure suggestion. We have decided to go down this route and they are proving quick and stable - a good way to call legacy code.

We are using the Idb2 data provider for the connection - this is the quickest way to communicate with the Iseries.


Thanks again.

Mike

Hi Mike,

Why haven't you considered the WCF proxies option? I'm also very interested to know how is it going so far with the Stored Procedure option. Has it been stable?
We might start doing something similar and I have few concerns with this regards:
1. First and foremost how are you creating those SP wrappers?
2. Are you using it for both data manipulation and fetching? You seemed to have issues with the blockfetch, did you manage to convert them to SQL result sets?

I would really appreciate your feedback.

Thanks in advance.
Eyad.

eyad wrote:

Hi Mike,

Why haven't you considered the WCF proxies option? I'm also very interested to know how is it going so far with the Stored Procedure option. Has it been stable?
We might start doing something similar and I have few concerns with this regards:
1. First and foremost how are you creating those SP wrappers?
2. Are you using it for both data manipulation and fetching? You seemed to have issues with the blockfetch, did you manage to convert them to SQL result sets?

I would really appreciate your feedback.

Thanks in advance.
Eyad.

Hi,

I no longer work with Plex (thanks CA for your help in my career!) or for the company I was working with when I posted this.

However thinking back what we did was :-

a. For fetch functions create an SQLRPGLE wrapper program with some embedded SQL to SET RESULT SET for the output parameters.
You can use this for block fetches as well because you can set the result set based on a data structure - google this - I cannot remember the exact syntax.

It was a little clunky as I had to inspect the generated code and see what the generated name was of the data structure was (generally V00001 or something like that).
I had to edit the SQL source code for each wrapper so the patternisation was not perfect - it just meant you had to check the generated code for each wrapper.
N.B. the wrapper called the blockfetch and populated the fetcheddata into a local variable.

If you have output parameters as well as fetcheddata you can use output parameters on the SP.

b. For update functions I had to seperate the parameters into seperate variables in a wrapper function so the stored procedure could be set up with seperate parameters.
Make sure you define the SP with PACKED / ZONED correctly. This was a bit of a pain because some legacy update functions had many, many parameters with a single variable - grunt work!

Basic architecture was .net front end calls stored procedure created using CREATE PROCEDURE with input parameters and a single result set (where required). These SPs are linked to a Plex wrapper program generated in SQLRPGLE. The wrapper then calls the legacy PLEX programs and maps output to a result set with embedded SQL.

Because Stored Procedures are standard SQL objects they are handled in a standard manner by .net with no need for Plex .net runtime which was not at all stable in a web environment. It was quick and stable - good solution.

Having used wcf now I can say it would have been perfect for platform home loans.

Absolutely no coding in plex or messing around with source or green screen command lines or anything, just gen and build wcf. Considering the front end was Microsoft you could have had the state full problem sorted out for free also using the different bindings.

Ca are suggesting that I store the instance of the Plex runtime object in the .net session state. This is the object created when you do ObApplicationUser app = new ObApplicationUser();

I have tried storing this in the Session state and I get an error saying ObApplicationUser is not serializable.

Is it possible to store the Plex runtime in the session state?

Mike_Hughes wrote:

Ca are suggesting that I store the instance of the Plex runtime object in the .net session state. This is the object created when you do ObApplicationUser app = new ObApplicationUser();

I have tried storing this in the Session state and I get an error saying ObApplicationUser is not serializable.

Is it possible to store the Plex runtime in the session state?

Mike,

I think that non-serializable objects can only be stored when the session state is saved in process, and not if you're using an out of process store (ASPState or SQL Server).

You might want to consider object pooling to store the Plex runtime object.

Regards,
Jeremy Hutchinson
Desynit Limited
:: Plex Wiki :: 2E Wiki ::
:: Plex/2E Feed Aggregator ::
:: Edge Forum Archive ::

Thanks Jez but I am trying to save in the IN Proc Session state using:

if (Session["PlexRunTime"] == null)
{
Session["PlexRunTime"] = new ObApplicationUser();
}


and it is giving me the 'object not marked as serializable' error. I believe this is the in proc session n'est pas?

Update: It is definitely using the in proc mode of session which is the default anyway. The problem is that obApplicationUser class does not implement ISerializable so there does not seem to be any way to store the object.

Hi Mike,

What is the full stack trace that you get, it might be somehting further up that is causing this.

Everything I've been reading suggested that non-serializable objects could be stored in the session if it were InProc.

That said on http://msdn.microsoft.com/en-us/library/aa478989.aspx, if you scroll down you'll see:

References to COM Objects

A common technique in traditional ASP was to use Session variables to store references to COM objects so that they can be used at a later time:
Listing 17. Storing a COM object reference

Set Session("MyObject") = CreateObject("WhatProc.WhatProc")

If you intend to employ this technique in ASP.NET, then you must store all session information in process (the default option). Attempting to store it in either the Windows Service or SQL Server results in an error similar to the following:

The type System.__ComObject in Assembly mscorlib...is not marked as
serializable.


In addition, if you wish to store Session references to regular .NET classes, then they must be serializable.


The important bit the last sentence.

The .Net runtime for Plex is not a COM object as far as I'm aware, but perhaps you could use the com connectors to expose the Plex objects and store these in the session?

The downsides to InProc sessions are that these will not server a worker process recycle, nor be used in a webgarden etc. Maybe object pooling is the way to go.

BTW, you've probably already guessed, but I've never tried any of this - just googling :-)

Regards,
Jeremy Hutchinson
Desynit Limited
:: Plex Wiki :: 2E Wiki ::
:: Plex/2E Feed Aggregator ::
:: Edge Forum Archive ::

Jez,

here is the stack dump - as far as I am aware we are using InProc - this is the default when writing to the session I believe.

Type 'ObRun.ObMain.ObApplicationUser' in Assembly 'Plex.ObRun, Version=5.5.0.0, Culture=neutral, PublicKeyToken=3ea450f96cbb47da' is not marked as serializable.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Runtime.Serialization.SerializationException: Type 'ObRun.ObMain.ObApplicationUser' in Assembly 'Plex.ObRun, Version=5.5.0.0, Culture=neutral, PublicKeyToken=3ea450f96cbb47da' is not marked as serializable.


Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:


[SerializationException: Type 'ObRun.ObMain.ObApplicationUser' in Assembly 'Plex.ObRun, Version=5.5.0.0, Culture=neutral, PublicKeyToken=3ea450f96cbb47da' is not marked as serializable.]
System.Runtime.Serialization.FormatterServices.InternalGetSerializableMembers(RuntimeType type) +7736027
System.Runtime.Serialization.FormatterServices.GetSerializableMembers(Type type, StreamingContext context) +258
System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitMemberInfo() +111
System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.InitSerialize(Object obj, ISurrogateSelector surrogateSelector, StreamingContext context, SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter, ObjectWriter objectWriter) +161
System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo.Serialize(Object obj, ISurrogateSelector surrogateSelector, StreamingContext context, SerObjectInfoInit serObjectInfoInit, IFormatterConverter converter, ObjectWriter objectWriter) +51
System.Runtime.Serialization.Formatters.Binary.ObjectWriter.Serialize(Object graph, Header[] inHeaders, __BinaryWriter serWriter, Boolean fCheck) +410
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream serializationStream, Object graph, Header[] headers, Boolean fCheck) +134
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream serializationStream, Object graph) +13
System.Web.UI.ObjectStateFormatter.SerializeValue(SerializerBinaryWriter writer, Object value) +845

[ArgumentException: Error serializing value 'ObRun.ObMain.ObApplicationUser' of type 'ObRun.ObMain.ObApplicationUser.']
System.Web.UI.ObjectStateFormatter.SerializeValue(SerializerBinaryWriter writer, Object value) +3395
System.Web.UI.ObjectStateFormatter.Serialize(Stream outputStream, Object stateGraph) +110
System.Web.UI.ObjectStateFormatter.Serialize(Object stateGraph) +57
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Serialize(Object state) +4
System.Web.UI.Util.SerializeWithAssert(IStateFormatter formatter, Object stateGraph) +37
System.Web.UI.HiddenFieldPageStatePersister.Save() +79
System.Web.UI.Page.SavePageStateToPersistenceMedium(Object state) +105
System.Web.UI.Page.SaveAllState() +236
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1099

System.Web.UI.HiddenFieldPageStatePersister.Save() +79

That looks like it is trying to save at least some of the state to the client as a hidden field in the webpage... and the Plex runtime is being included as part of this. That's not going to work.

I don't know why the Plex runtime is being included as part of the Page/View state, but you either need to get it to use the SessionPageStatePersister to store it in the in process session, or find out how not to include it in the page state.

Regards,
Jeremy Hutchinson
Desynit Limited
:: Plex Wiki :: 2E Wiki ::
:: Plex/2E Feed Aggregator ::
:: Edge Forum Archive ::

hmm... interesting. I am getting to the limits of my knowledge. I am not sure why asp would try to save the session to a hidden field - does this indicate state server is being used rather than InProc?

I really think this is the sort of thing that should be documented by CA (how to persist the runtime). Or am I just being naive?

Try adding

<asp:Page EnableViewState="False" />

to the page and see if that makes a difference. The default is to enable the view state.

http://msdn.microsoft.com/en-us/library/system.web.ui.page.enableviewstate.aspx

Regards,
Jeremy Hutchinson
Desynit Limited
:: Plex Wiki :: 2E Wiki ::
:: Plex/2E Feed Aggregator ::
:: Edge Forum Archive ::

Jez,

You were right about the disable view state - I disabled it and asp allowed me to save the ObApplicationUser to the session and the first fetch works OK.

However, when I try to save or refresh the page the method GetInputParmDataSet falls over with the stack below. Even though the ObApplication User object is not (to our view) being used by this method. I have debugged the function and the runtime object is not null. This really is very frustrating - I am not getting much joy off CA.




Key cannot be null.
Parameter name: key
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.ArgumentNullException: Key cannot be null.
Parameter name: key

Source Error:


Line 27: DataSet dsOutput = new DataSet();
Line 28:
Line 29: dsInput = ObUserApi.getInputParmDataSet("PlexDotNetShells.FetchAcceptanceReceipt_ObIn");
Line 30:
Line 31: dsInput.Tables["CallInfo"].Rows[0]["Environment"] = "PlexDotNetShells";


Source File: T:\IT Systems\IT Systems Data\Development\dotNet\Webbrowser.net\PIL\Platform.PIL.WebBrowser\Platform.PIL.WebBrowser\PlexCalls\AcceptanceControl.cs Line: 29

Stack Trace:


[ArgumentNullException: Key cannot be null.
Parameter name: key]
System.Collections.Hashtable.get_Item(Object key) +7487019
System.Collections.SyncHashtable.get_Item(Object key) +12
ObRun.ObMain.ObApplication.get_ObAssemblyList() +117
ObRun.ObMain.ObApplication.getClassForName(String className, Boolean log) +98
ObRun.ObUtils.ObUserApi.getInputParmDataSet(String name) +137
Platform.PIL.WebBrowser.PlexCalls.AcceptanceControl.GetAR(Int32 customerNumber, Int32 sessionID, ObApplicationUser app) in T:\IT Systems\IT Systems Data\Development\dotNet\Webbrowser.net\PIL\Platform.PIL.WebBrowser\Platform.PIL.WebBrowser\PlexCalls\AcceptanceControl.cs:29

[TargetInvocationException: Exception has been thrown by the target of an invocation.]
System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) +0
System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) +71
System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) +261
System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) +29
System.Web.UI.WebControls.ObjectDataSourceView.InvokeMethod(ObjectDataSourceMethod method, Boolean disposeInstance, Object& instance) +488
System.Web.UI.WebControls.ObjectDataSourceView.ExecuteSelect(DataSourceSelectArguments arguments) +1247
System.Web.UI.DataSourceView.Select(DataSourceSelectArguments arguments, DataSourceViewSelectCallback callback) +19
System.Web.UI.WebControls.DataBoundControl.PerformSelect() +142
System.Web.UI.WebControls.BaseDataBoundControl.DataBind() +73
System.Web.UI.WebControls.FormView.DataBind() +4
System.Web.UI.WebControls.BaseDataBoundControl.EnsureDataBound() +82
System.Web.UI.WebControls.FormView.EnsureDataBound() +166
System.Web.UI.WebControls.CompositeDataBoundControl.CreateChildControls() +72
System.Web.UI.Control.EnsureChildControls() +87
System.Web.UI.Control.FindControl(String id, Int32 pathOffset) +23
System.Web.UI.Control.FindControl(String id, Int32 pathOffset) +327
System.Web.UI.Control.FindControl(String id, Int32 pathOffset) +327
System.Web.UI.Control.FindControl(String id, Int32 pathOffset) +327
System.Web.UI.Page.FindControl(String id) +38
System.Web.UI.Page.ProcessPostData(NameValueCollection postData, Boolean fBeforeLoad) +232
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1743

Hi, saving Plex objects in session doesn't guarantee that the handle will be valid in next request. You should try ThreadContext.

Best regards

thanks for your post manuel. Could you provide more information please? It was CA who suggested using the session.

Hi, again

I don't know what CA suggests. From ASP.NET point of view, depending on your site configuration is very likely that each request is going to be processed for a thread taken from a pool and is very likely that the next request (even postback) may be handled for another thread in the same session pool. In such a situation you get the error you are complaining of. This is easy to check in VStudio with a little debugging.

So, you have two lines of work (besides messing with IIS and ASP.NET configuration):

-Create a separate thread and create in it your ObApplicationUser object (and then deal with sending all operations to this thread). Not easy, I'm afraid.

-Save key values and relevant info in ViewState and store your ObAppl... handle in ThreadContext (you can get it through the Page object and the usage is very similar to the Session) In the next request, if the thread is the same you can get your handle back. If not, your handle will be null but you can recreate the object and state (for example, position)

If you choose to mess with ASP.NET, try to reduce every session to just one thread. But this is only possible if you have full control of your execution environment. Unfortunately, Plex runtime objects doesn't accept multithreading very well.

Best regards

Regarding my previous post, I must add that the first solution is not easy but it isn't far too difficult either. You just have to keep exchanging info forth and back using datasets and be somehow careful. This option is worth if you are going to use it pretty often. And I'm referring to create several applications for the Web with Plex not just a few pages.

thanks for your suggestions Manuel. However, I am coming to the conclusion that creating a persistent ObApplicationUser is not the solution to our connection issues.

We are connecting to the Iseries by a Plex C# function calling a Plex RPG function. As the Plex C# function will not be using the ObApplicationUser object we created it will not be of help in connecting.

There is also the problem of flakiness of the connection - we regularly get a failure to connect - we do not know why there is no error or feedback of any kind. CA do not seem to have a support team any more who knows Plex.

Hi again,

Ok, but please tell me how do you intend to call/initiate your C# function?

Best regards

we create an instance of ObApplicationUser, call ObUserApi.getInputParmDataSet to set the input parameters, then use M_ObCallMgr.obCallFunction to call the Plex c# function.

This is all as advised in the Plex help and the sample model.

Mike_Hughes wrote:

we create an instance of ObApplicationUser, call ObUserApi.getInputParmDataSet to set the input parameters, then use M_ObCallMgr.obCallFunction to call the Plex c# function.

This is all as advised in the Plex help and the sample model.

Sorry if I keep asking for info but it seems I'm missing something...

Previously you stated:

===================================================================================
We are connecting to the Iseries by a Plex C# function calling a Plex RPG function. [color=#E10B16]As the Plex C# function will not be using the ObApplicationUser object we created it will not be of help in connecting[color]===================================================================================

Now you say you are using ObApplicationUser, so I don't understand what is the matter...

ObApplicationUser objects can be persistent what they don't do is to persist across different threads.

Best regards
Manuel

we are creating an instance on ObApplicationUser and storing it in the Session - this is in pure asp / c# world. We use this object call a Plex generated c# functions. These Plex c# functions then call Plex RPG functions.

The method that Plex uses to call from Plex C# to Plex RPG is hidden from us and (presumably) does not use the ObApplicationUser object that we created.

Hi Hughes

After chatting offline I had to check what .net you were talking about as my approach seemed too obvious, maybe wrong, but obvious so wanted to check what plex generated .net you were talking about with out me looking silly, incase you replied on the forum we are using WCF.


Dump this approach, it sounds like you are still at Proof of Concept stage. It all seems far too techy and if something is taking too long then usually it means it is the wrong solution.

I'd upgrade to 6.1 Plex and getting using WCF.

From help

Calling Plex generated WCF Services from .NET Client Applications

The whole point of creating WCF services is so that you can integrate your Plex applications with other applications and integrate them in business processes. The first way to use WCF services is to create a .NET application that accesses your running service. This .NET application could be any of the following types of application:

Windows Forms
ASP.NET
Windows Presentation Foundation
Windows Workflow



I feel you could get the .net framework to work for you more easily in this case rather than your other approaches.

Cheers
George