All,
I have a package that calls another package via a Java Service. The package name that the Java Service calls is built at run time based on information from the profile. The called package returns a record in the pipeline but that record will have a different name based on the package called.
How do I pull that record out of the pipeline when the package execution completes?
Thanks in advance
Chris Linton, DESC Technologies Inc., chrisl@desctech.com, www.desctech.com
Is this an option?
You cannot add a variable to the visible pipeline without manually adding it using Flow or an as input/output. If your dynamically-generated records will all have the same structure, this is probably the simplest way to do it.
I think, even if your dynamically-generated records dont have the same structure, you can still use the option described by Dan.
Just ensure that you do a branch on the specifier (on which structure to use) in the flow service, and accordingly map dRecord to StructRecord
Let me know if I was too cryptic above.
Thanks.
Dan,
The records will have different names but there is a pattern.
ie X12_4010_810, X12_3050_810.
The record is already visible in the pipeline as I can see it on the results tab. My problem is I need to map to the Values in convertToString. Can I map a dynamic record to convertToString?
Someone presented an option of using branches and in this case it may be feasable as there will be only 4 different record formats but then my service is no longer generic as it would require a code change if a new format is added.
Chris
Will there be no other code changes (apart from change to this flow service) if a new format is added ???
Saurabh,
That’s correct for this generic package. This package picks up the flat file from the backend, queries the extended fields in the profile to determine the partner (DIB), the standard (X12), the version (4010), etc. Based on this I know that my Interface is DIB, my service is DIB_X12_4010_810 which puts the record X12_4010_810 into the pipeline. IF a new partner is added I need to create a new package for that partner only. If a partner changes versions then I have to modify that partner’s package only.
Chris
Then I suppsoe what Dan suggested works the best for you !!
you already know what the record name is, and in a similar fashion you know what flow service to invoke to process that record created by the java service.
Thus, for your case, you will have 4 different flow services existing in those partner specific packages or interfaces, and which will copy the dRecord to StructRecord
I assume the purpose of your ensuring the record to be correctly mapped is that you want to process it further in a partner package/interface.
we have a very similar solution implemented in our case too !!
Thanks
Saurabh.
sm195@lucent.com
973-386-6850
Chris: Have you considered using TN and the EDI adapter to do this doc recognition and service invocation? If you use them, then adding a new doc type becomes a TN configuration task, along with writing simple map services that will be invoked only in the conditions you specify in the TN rules.
If you’re going to press forward with what you have, a way to avoid the need to modify the main service every time a new doc type is added is to have the service that determines the partner, standard, version, etc. also look up the name of the mapping service to use. Then you don’t have to branch at all. Just invoke the service that is named.
Rob,
I am using the EDI Adapter. But before I can send my the doc to TN I have to get it into an EDI format. This is outbound flat file to EDI. The dynamic service called by my Java service puts the dynamic EDI record into the pipeline. My problem was accessing that EDI record so that I could envelope it and send it off to TN. I’m following the wmEDISamples process. If I’m on the wrong track please let me know.
This thread may be getting off topic from the original message so you may want to email me directly.
Thanks to all for your speedy replies.
Chris Linton, DESC Technologies Inc., chrisl@desctech.com, www.desctech.com
Ah, gotcha.
If I understand what you’re doing correctly, the following should do what you need.
The dynamic service should always return the same record name in the pipeline. There is no real need for it to be different for each package. Think of your dynamic services as implementing a method of a Java interface–you pass in vars with specific names and you get back vars with specific names. In this case, perhaps X12_rec or EDI_rec would work. This will be passed to convertToString as the Values parm.
The dynamic service should return the full namespace of the record being returned. Seems like you already have that more or less in place as the name of the record in the pipeline so only minor tweaks would be needed to place the name in the pipeline in a variable named X12_recName or EDI_recName. Pass this to convertToString as the nsRecord parm.
Unless you’re doing some mapping from/to your EDI record structure within the main service, the above changes should do the trick.
Hope this helps.
Rob,
I just don’t get it. I seem so close.
My dynamic service does return a different record name depending on the version of EDI for that partner. ie X12_4010_810 or X12_3010_810. I can see my X12_4010_810 record in the pipeline when the dynamic Java service completes. All I need now is to access it so that I can map it to the values in convertToString.
If anyone has a sample that they can share I would greatly appreciate it or if you want to talk to me directly email me your number.
Thanks again.
Chris,
If you have the WmEDI package, check out this flow for ideas:
wm.b2b.edi.util:invoke
INPUT:
T - Interface
T - service
RecordValue - input
OUTPUT:
RecordValue - output
I assume that you are using:
do.invoke(packagename, input, output)
See if you can play around with using the EDI invoke tool.
output dynamic java service :
recordName
record
convert the record to recString using pub.record:recordToXMLValues
Requirement:
send it to TN, which in turn based on procesingRules invokes a service. lets assume, that service is flow service
input to this flow service:
recordName
record or recString
code for flow service:
map the record to your specific record structure based on the expected recordName
or convert recString using pub.record:XMLValuesToRecord and proceed as above…
Hope I am getting your needs correct.
-Saurabh
973-386-6850
sm195@lucent.com
I’ll try a different description.
As you’ve seen, calling a service indirectly presents a challenge. By indirectly I mean via a Java service, such as Chris appears to be doing, or via wm.b2b.edi.util:invoke as Ray suggests (there is also a service wm.marketplace.util:invokeService that does the same thing).
I don’t know how Chris’ service looks, but the marketplace.util:invokeService has this input/output signature:
input: ..$service -- string, the full name of the service to invoke output: ..none
and edi.util:invoke looks like this:
input: ..interface -- string, the full folder name holding the service to call ..service -- string, the name of the service to call ..input -- record, a record holding the input parms for the service to call output: ..output -- record, a record holding the output parms from the called service
Though these have different parms, these behave the same way and present the same “how do I get access to the output parms?” issue.
For both of these, you have to know what the inputs/outputs of the called service are. For example, you might invoke a service named utils:mapMe that has these inputs/outputs:
input: ..sourceRec -- record, the flat-file record to convert output: ..targetRec -- record, sourceRec converted to an EDI record structure ..targetRecName -- string, the full name of the EDI record structure
For this service to work, there must be a pipeline var named sourceRec when the service is called. When the service is done, two new pipeline vars will exist–targetRec and targetRecName.
Okay, now we have the basics. Let’s look at the “main” flow that calls mapMe indirectly. It probably does some housekeeping first, setting things up and then does the call something like this:
... -- housekeeping calls ... -- derive or lookup from extended fields, the service to invoke ... -- assume "utils:mapMe" is the contents of serviceToInvoke MAP vars to sourceRec INVOKE wm.marketplace.util:invokeService ..serviceToInvoke --> $service ...-- Now what? The design-time pipeline doesn't show targetRec and targetRecName!
There are two approaches to get access to targetRec and targetRecName.
The first is add a MAP or INOVKE step, depending on what you need to do, after the invokeService call. Click the “Pipeline In” area on the left side of the pipeline pane. Add a Record or Record Reference named targetRec and a string named targetRecName and map from them just as you would any pipeline var. This is essentially “declaring” these variables in the pipeline and will access the vars returned by utils:mapMe.
The second is to not call invokeService directly, but write a wrapper service that explicitly shows the inputs and outputs for this type of service. For example:
service: invokeSourceToTargetService inputs: ..service -- string, the full service name to invoke ..sourceRec -- record, the flat-file record to convert output: ..targetRec -- record, sourceRec converted to an EDI record structure ..targetRecName -- string, the full name of the EDI record structure
There is only one step in this flow:
INVOKE wm.marketplace.util:invokeService ..service --> $service
The parms for invokeSourceToTargetService make the pipeline vars available to the caller. Our main service can now call this service instead of invokeService:
... -- housekeeping calls ... -- derive or lookup from extended fields, the service to invoke ... -- assume "utils:mapMe" is the contents of serviceToInvoke INVOKE invokeSourceToTargetService ..serviceToInvok
Rob and the entire community.
Thank you very much for the effort and time spent on this.
I have tested your first scenario and it has resolved my problem.
I look forward to your article in the next eZine.
Chris
Chris Linton, DESC Technologies Inc., chrisl@desctech.com, www.desctech.com