| Author |
Message
|
| kriersd |
 Posted: Fri Oct 15, 2004 12:16 pm Post subject: Automating the imprt of FDL into runtime |
 |
|
Master
Joined: 22 Jul 2002
Posts: 209
Location: IA, USA
|
Does anyone currently have a strategy for automating the deployment of FDL. I work in a large company on the Workflow support team. My team supports the Workflo infrastructure for the whole company. We have business units develop their own process models and then place the FDL file in a staging directory. Once the file is placed on the directory a member of my team will copy the file to the Workflow server and perform the "fmcibie" import manually. Now that more and more business areas are using Workflow, we have several staging requests each and every day. I am looking for a way to automate the FDL import. I am tossing around the idea of building a Workflow process model to service the importing of FDL into Runtime. Does anyone have any ideas or suggestions on how to manage FDL imports?
I am totally open to anything at this point.
_________________
Dave Krier
IBM WebSphere MQ Workflow V3.4 Solution Designer |
|
| Back to top |
|
 |
| vennela |
| Posted: Fri Oct 15, 2004 10:06 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
I currently have automated this one.
Ofcourse this is only in development and test. Production still needs me do that.
This is what happens.
There is a specific directory where developers can put their FDL. After they put their FDL in that directory, they logon to workflow and start the workflow process designed for this specific automation process. During the startup of this workflow process, they will have to give thier FDL name.
The first activity in the workflow is a UPES activity and this is a sanity checker. I have written a java program which will scan through the FDL to see if the FDL has any unauthorized stuff in it. For example, import ADMIN user, or importing anything under NETWORK tab etc.
After that is done, user will get a notification saying their FDL is ready to import. If they click on yes, their FDL will be imported and the fmcibie's output (log file of fmcibie) will be available for them. |
|
| Back to top |
|
|
| nathanw |
| Posted: Sat Oct 16, 2004 1:39 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
vennela
thsi is going to be veru useful for a project i am on down here in south africa.
any chance yu could send me by email a copy of this and an idiots guide as i need to ensure a non websphere in house support person can do this when i roll off.
manay thx |
|
| Back to top |
|
|
| vennela |
| Posted: Sat Oct 16, 2004 7:48 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| I am not sure if I can send the stuff out. But I can definitely help you build it. |
|
| Back to top |
|
|
| kriersd |
| Posted: Tue Oct 19, 2004 9:58 am Post subject: |
|
|
Master
Joined: 22 Jul 2002
Posts: 209
Location: IA, USA
|
Hi Vennela,
This process is much the same as we have today minus the Workflow process. We too built an FDL text scanner that scans the FDL for things like the word ADMIN and DOMAIN, but it's a manual step at this point. I am toying with the idea of building a Workflow process model to automate this, much like you already have. This is interesting to me, because your example was very close to what I vision. Would you or anyone else care to prototype a process model for such an application? By prototype I mean work through the design process together. I too can not share any real FDL outside the company, but I can share my knowledge of how one would build such an application.
Here is my first problem that I just can't seem to make a decision on.
How to initiate the process and capture the FDL?
Option 1.) You could have a web interface that allows the user to cut & paste the FDL into a JSP page. The backend servlet would then build the create and start XML with the FDL as the payload.
Option 2.) (Vennela's approach) The user would place the FDL file on a file system directory and manually start the process via the web client.
** Things to think about when evaluating the decision **
Security - How do you ensure the user is authorized to put new FDL into the Workflow runtime environment.
Import options - How do you collect the import options and pass them along with the FDL for importing.
Sync vs Asynch - Will there be a response to the users request or will they fire off the request and wait for a response later. ( I vote Asynch )
If anyone has any other suggestions please feel free to speak up. |
|
| Back to top |
|
|
| jmac |
| Posted: Tue Oct 19, 2004 1:20 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Dave:
As to capturing the FDL, I would go with the file system. You could then have a mechanism for a user to start the "FDL Maintenance" Process Model, and as inputs get the FileName of the FDL, and the user's email address.
If you have a directory which you secure, you could have your authorized users post the FDL to that directory, which should help with your security concerns. Your activity could be designed to strip off any directory information from the FDL File name, and always use the Approved directory. This way only an authorized user could post FDL to the directory, and you would only process FDL from the authorized directory.
If you intend to allow the users to use import options, you could easily imlement them via additional container members. But, is this necessary? I always use the same options, and never seem to have any problems. Since I might not trust all the users to use the proper switches, I might just use the same ones every time.
As to Sync/Asynch. I vote for Synchronous... at least to the extent that I would send back a notification (using the email address) that the import was complete. People are going to put FDL into your system and assume it was applied. I would say from day 1... you put FDL into the system, and we tell you whether or not it was applied. This way you don't get people complaining that they "validated their FDL in BT (or worse Modeler) and know it was clean" 
Just my thoughts
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| kriersd |
| Posted: Wed Oct 20, 2004 11:44 am Post subject: |
|
|
Master
Joined: 22 Jul 2002
Posts: 209
Location: IA, USA
|
Thanks for the reply Jmac,
I agree with you, the user should get a response indicating the result of the import. I was thinking more along the same lines as you, with an email response. I would tend to call that asynch processing because the response is not within the same transaction. But, never the less great minds think alike!  I also tend to always use a -f -o option so maybe we just default the import settings.
Ok so we have the initiate procedures figured out.
To start the process we would create a secured directory and allow the users to place their FDL in this directory. They would then go out the Web client and start the WF process. The process requires the following input fields:
Userid:
Email:
FDL File Name:
Environment: (Test|Pilot | Prod)
Import Time: [Immediate | Delayed]
If Delayed what time do you want to import the FDL: <Example 22:00>
Configuration: <Configuration ID>
Issue number II.)
How to prevent the developers from making admin changes such as: Changing the ADMIN password or making DOMAIN changes?
Option A.) Text scan the FDL for specific key words. (This would be my Vote)
Option B.) Do nothing and let the users import all fdl
If you do need to scan the fdl, what do you do when you find a reserved key word in the fdl? I would make the suggestion routing the work to a Workflow admin for approval. Sometimes the key word search may flag a word that was in the description of an activity. If the FDL does in fact need to be rejected the Workflow admin could then make some comments to be placed in the email back to the developer telling them why it was rejected.
Just some more of my random thoughts. |
|
| Back to top |
|
|
| jmac |
| Posted: Wed Oct 20, 2004 11:52 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Dave:
I am definitely for Option A.
The only issue with routing to an admistator type, is that you would likely have to establish some turnaround guidelines. I am more in favor of the outright rejection. If you pick your keywords carefully enough you should weed out most false positives. And if your email note says, something like "We are rejecting this FDL, if you think this is an error, please contact blah".
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| kriersd |
| Posted: Fri Oct 22, 2004 10:30 am Post subject: |
|
|
Master
Joined: 22 Jul 2002
Posts: 209
Location: IA, USA
|
I do agree, we need to be careful on how we scan the FDL. The more automated the import is the better off we are.
I was really thinking this option could be easier on the admin person. If the Workflow administrator has the ability to make a decision and click one button to let it go through it might make things easier on both parties. There are times in our environment where the scanner will reject the FDL, but there has been a prior agreement made to let the FDL go through. We would then just ignore the error messages from the scanner because we were prepared to see a few errors. We still look for other errors in the scan that were not previously discussed with the customer. I guess this may be a unique approach for my company. In general this option may not be well suited for other companies. This approach would eliminate the need to manually import FDL that wouldn't pass the scan.
Have a good weekend
Dave
_________________
Dave Krier
IBM WebSphere MQ Workflow V3.4 Solution Designer |
|
| Back to top |
|
|
| vennela |
| Posted: Fri Oct 22, 2004 11:17 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
Scanning the FDL for key words which the developers are not supposed to use is not that tough. Like John said, if you carefully observer the FDL and FDL syntax you can easily eliminate things.
For example:
I don't look for the keyword ADMIN. Because there might be a person called DVDADMIN, a user for who is the default process started for a process. Rejecting the FDL then is not right. But I look for the keyword PERSON 'ADMIN'.
I also don't allow developers to created UPESs. So, I have to see if their FDL is either creating deleting or replacing or updating UPESs. So instead of looking for SERVER I look for the words like UPDATE SERVER combined.
FDL has some alternative syntaxes also. For example
PERSON 'ADMIN' i same as PERSON "ADMIN" (with double quotes)
Also PERSON "ADMIN" is same as PERSON "ADMIN" (with multiple spaces between PERSON and ADMIN). To avoid this, before I scan the FDL, I remove multipl spaces in the FDL and then scan it.
I also provide the entire output of the fmcibie to the developer when the import is automatically done. If it went through then that's fine. If not he can see the log and know why his FDL fails, maybe because one of the datastructures in his FDL is missing or maybe he hasn't done the verify before importing etc. |
|
| Back to top |
|
|
| anveshita |
| Posted: Tue Nov 02, 2004 2:11 pm Post subject: |
|
|
Master
Joined: 27 Sep 2004
Posts: 254
Location: Jambudweepam
|
I would like to try a different approach. this is my utopian concept.
1. Users will request the helpdesk to change the authorization/reset password through an e-mail
2. Helpdesk receives the information and enters it on a JSP(customized)
3. A custom FDL will be created and a web service is requested to import the FDL into run time
4. A response will be displayed to the help desk person whether the import is successful |
|
| Back to top |
|
|
| vennela |
| Posted: Wed Nov 03, 2004 6:25 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
|
| Back to top |
|
|
|
|
