Browse Category

Oracle EPM

Technology information pertaining to Oracle’s EPM platform

Kscope13 Recap

As with previous years, this year’s KScope conference did not disappoint!  The location, people, and content were all great.

While the weather in New Orleans was hot, the close proximity to many local attractions was cool and made it easy to explore the town between sessions.  The Sheraton was but steps to local dining, shopping, the historic French Quarter, and the Mississippi.  If you wanted to travel farther out, you simply had to walk out the front door and hop on a trolley car.

The record breaking drives of worldwide people who participated at the conference were great!  The organizers, venue staff, ODTUG Board Members, presenters, vendors, and attendees were all welcoming, helpful, and focused on making the conference successful.  The quality people that attend this conference make the conference special.

Overall, the content was exceptional.  Attendees had their pick of high quality content in all of the regular areas and even a few new areas such as .NET programming!  Oracle was on-hand to discuss the latest and greatest releases, consultants shared some of their secrets and best practices, vendors demonstrated their products, and employees provided real world case studies.

A few of my personal favorite sessions were:

* – Biased as this was MY session!

Speaking of sessions, I once again fielded a session focusing on API programming in EPM.  Unlike the 2012 session which took a shotgun blast approach to all sorts of EPM APIs, this year’s session shined a laser on the HFM COM API.  The goal of the session was to walk the attendees through an entire application build from scratch.

We covered installing the necessary HFM files to your computer, installing a development environment (Visual Studio), creating your first project, adding the necessary DLL file references, implementing key API calls, and compiling/executing your first program.  To further help the attendees get started, I provided a complete sample project that users could use as a starting point.

In case you missed my session(s) or you want a copy of the presentation deck, you can find them here:

2013 Session : https://www.box.com/s/ttapg8dcwebw7z9p0k0x

2012 Session : https://www.box.com/s/a2ea627ae8c6f38c674c

NOTE:  Links to source code are included in the files at the end of the slide decks.

Hope to see you at Kscope14 in Seattle!

Charles

Mardi Gras World
Mardi Gras World
NOLA Trolley Car
Trolley Car
What would happen if .....
What would happen if …..

 

HFM Subcube Architecture Documents (Pre-11.1.2.2)

Recently a saw a colleague asking for some information about the HFM table layout and how they could interface with the data in the system.  While I recalled there were a few documents on the subject, I could not locate them via Google.  While I’ve provided them at the bottom of this blog post, I thought I’d give a 10 second high level explanation of the primary tables in regards to the actual HFM data.  (Pre 11.1.2.2)

Generally speaking, when you configured HFM, you provided a database for use by the system.  This database will hold the data for all of your applications created in the envirionment.  To keep the data separated, each application’s data tables will be prefixed with the application name.  (i.e. SampleApp_CSE_11_2011)

Oracle is kind enough to publish a data model breakdown for most of the tables which can be found here:
http://www.oracle.com/technetwork/middleware/bi-foundation/resource-library-090986.html

Interestingly, they do not cover all of the tables as they appear to skip over the data tables.  When it comes to the data, there are 3 primary tables that hold the financial information : DCE, DCN, and DCT tables.  The DCE tables store <Entity Currency> and <Parent Currency> values and the related adjustments. The DCN tables store data for the remaining members of the value dimension. The DCT tables store the journal transactions – when the journals are posted, the data values flow to the DCE and/or DCN tables.

When viewing your database, you will see a series of tables that follow a relatively obvious naming convention:
<App_Name>_DCE_<PeriodNum>_<Year>

Elevator Trivia Note: The fact that the Period and Year and part of the naming convention is a key reason as to why you specify an ending year (and number of periods) during the App build process!

Looking at the structure of these tables, you’ll see the following fields used consistently:

lEntity
lParent
lValue
lAccount
lICP
lCustom1
lCustom2
lCustom3
lCustom4

With the exception of lValue, these are pretty straightforward and act as foreign keys back to the respective tables such as <AppName>_Entity_Item.

lValue – Is slightly different as it takes a little work to determine what this is.  For each currency in your system, you will have Base Currency “Entity Currency”, Adjustments, and Total.  This field is a combination of that AND the currency.  The following formula will help you translate:

<AppName>_CURRENCIES.ItemID * 3 + 15 = “Currency Total”
<AppName>_CURRENCIES.ItemID * 3 + 16 = “Currency Adj”
<AppName>_CURRENCIES.ItemID * 3 + 17 = “Currency”

In addition to those fields, the tables all contain one or more Timestamp field.  Minor conversion is needed on the Timestamp field to make it human readable.  For instance in SQL Server you would return it as:

cast(TimeStamp2 as smalldatetime)

After these columns, each of the 3 table sets have slightly different layouts; however, one additional pattern you should see is that there will be incrementing columns that correlate to the number of periods in your application.  One of the columns will hold your actual data while the other one will hold a timestamp or some sort of indicator about the data (i.e. Trans Type)

Armed with this knowledge, one thing you can do is search all of your data tables to find orphaned information.  While Oracle gives you a way to clear it out, it doesn’t give you a good way to see what you are clearing.  With a basic query, we can not only find out if we have orphaned records, but what the data is and when it was created/last used/updated!

The following Microsoft SQL Query will dynamically go through ALL tables that reference lEntity and then determine undefined values.
NOTE: You should theoretically search for Account, ICP, and Custom orphans as well, but this is a start!

_________________________________
— Get List of Tables that refer to Entity ID and then search them all looking for undefined values

— NOTE: You would probably do the same for lValue, lAccount, lICP, lCustom1 – lCustom4,

— NOTE: lParent would correspond to entity table like lEntity

— NOTE: lSrc and lDes should also be checked against actual table. i.e. lSrcAccount checked against Accounts

 

–Initialize some working memory

Declare @tblSearchTable varchar(50)

Declare @tblSrcTable varchar(50)

Declare @tblSearchField varchar(50)

Declare @sql nvarchar(4000)

— Setup defaults

set @tblSearchField =‘lEntity’

set @tblSrcTable =‘<APPNAME>_entity_item’

–Setup Cursor

Declare tmp_cursor CURSOR

For Select distinct name from sys.tables where object_id in ( select object_id from sys.columns where name= @tblSearchField) order by name asc

Open tmp_cursor

–Retrieve Table name to process

Fetchnextfrom tmp_cursor

INTO @tblSearchTable

WHILE@@FETCH_STATUS= 0

BEGIN

SET @sql=‘select ”’+ @tblSearchTable +”’ as SrcTable, * from [‘+ @tblSearchTable +‘] where ‘+ @tblSearchField +‘ not in (select itemid from [‘+ @tblSrcTable +‘])’

EXECsp_executesql @sql

–Retrieve Table name to process

Fetchnextfrom tmp_cursor

INTO @tblSearchTable

END

CLOSE tmp_cursor

DEALLOCATE tmp_cursor

__________________________________________________

Additional Reading

Hyperion Subcube Architecture Document

HFM Tuning Guide

Enumerating Financial Reports via Workspace database

Disclaimer : This post will talk about direct database access. Do not perform unless you are sure you know what you are doing and I’m not liable! I’m just passing along information I’ve learned in case it helps you out….
Recently, we decided that we wanted to review all of our reports to determine which ones we could drop and which ones we should keep. Over the past 7 years, things have accumulated and we literally have thousands of reports gasp between all of the backups, Work In Process, and flat out duplication. In order to handle the review of this we wanted to assign prople to review specific sections of the reports. I was asked to provide a nice excel ‘report’ that would break down the report / folder hierarchy so that we could assign it.
That is when I realized that I really couldn’t locate a tool / report that would generate such a report listing!
In the old 7.2.5 version of Reports, it was relatively easy to get this information as all of the report information (including actual report content) was stored in a single database table.
With System 9 and Workspace, this is no longer true. With Workspace, the files are stored on the server’s file system in a manner consistent with the hierarchy of your reports/folders. Intially I thought I would be able to use this file system to build my report using simple DOS commands. (i.e. dir /s > reportlist.txt) Unfortunately though, the file names of the reports and folders are not ‘human readable’. (In order to decipher it, you’d have to go into the workspace database and x-ref these names to a table, etc)  Fortunately; however, you can build a report listing via SQL. The script below recursively builds a report with the following output :

(NOTE: Actually the script includes more columns of output; however, for display purposes here, I’m only showing the name and description)



Report Name     Description
AnnualReports NULL
===Actg-YContractual Obligations – Multiple Entities Contractual Obligations
===Annual Validation Summary Annual Validation Summary
===Customers and End User Markets NULL
====== 001 – End Use Markets Book End Use Markets Book
====== 002 – Top Customers Book Top Customers Book
====== 010 – Customers Book Reports – Corp NULL
========= Revenue by Top Customers – All Sectors – Pr Yr Comp Customer Revenues
========= Revenue by Top Customers – All Sectors – Pr Yr Comp -TEST Customer Revenues
====== 020 – Markets Book Reports – Corp NULL
========= Revenue by End User Markets – All Sectors End Use Markets
====== 030 – All Sectors – End Use Markets – Pr Yr Comp NULL
========= End Use Markets – Pr Yr Comp Customer Revenues

 


SQL 2005+ Query
USE BIPLus_prod;

GO

WITH Reports (PARENT_FOLDER_UUID, CONTAINER_UUID, NAME, DESCRIPTION, Level, Sort, CREATION_DATE, LAST_MODIFIED_DATE)

AS

(

— Anchor member definition

SELECT d.PARENT_FOLDER_UUID, d.CONTAINER_UUID, d.NAME, d.DESCRIPTION, 0 as level, cast(NAME as nvarchar(1024)) as sort, d.CREATION_DATE, d.LAST_MODIFIED_DATE

FROM V8_CONTAINER as d

WHERE d.PARENT_FOLDER_UUID = ‘0000011b42b29e00-0000-0b4d-c0a8e22a’ UNION ALL

— Recursive member definition

SELECT d1.PARENT_FOLDER_UUID, d1.CONTAINER_UUID, d1.NAME, d1.DESCRIPTION, Level + 1, cast(Sort + ‘|’ + d1.Name as nvarchar(1024)), d1.CREATION_DATE, d1.LAST_MODIFIED_DATE

FROM V8_CONTAINER as d1

INNER JOIN Reports AS r

ON d1.PARENT_FOLDER_UUID = r.CONTAINER_UUID

)
— Statement that executes the CTE

SELECT replicate(‘ ‘,Level) + NAME, DESCRIPTION, CREATION_DATE, LAST_MODIFIED_DATE, Level, PARENT_FOLDER_UUID, CONTAINER_UUID FROM Reports order by sort
GO


How this works :
The table V8_CONTAINER holds the main part of the report / folder entry data. In this table you will find Names, Creation Dates, Modified Dates, Owner name, UUID, and Parent UUID information. In order to build a hierarchy, you will need to pay careful attention to the UUID fields. CONTAINER_UUID is the internal name of the object in Workspace. (i.e. non-user friendly name) PARENT_FOLDER_UUID is a reference back to the item’s parent.
With this in mind, if you know the UUID of your starting point, you can simply recurse from there to get a listing of all folders and subsequent reports. In the script above I start off looking for an entry that is the starting point of our reports that we wanted to audit. For your purposes you will need to change this to what your starting point is.

NOTE : If you want to get everything in the table, use REPORTMART. REPORTMART is the parent to everything in the table.
I hope my walk through wasn’t terribly boring and helpful. I apologize for only providing a script that works in SQL Server; however, that is what we use at our site and there should be enough explanation here for someone relatively proficient with Oracle to write a similar script if they desire.

Synchronizing FDM (9.3.1) Applications w/ T-SQL

At my current location we have 1 main and 2 supporting FDM (9.3.1) applications. The main app is used to load production G&L data, and the supporting apps are used for loading our Budget and Forecast data and all are separated to ensure that a mistake in a multi-load template is minimized.
The problem we have with this setup is that we have to do 3x the maintenance work when it comes to users and locations.

While the users and locations are the exact same in each application, there are some differences; however: a.) Data Maps in Budget / Forecast are simply * to * as we use multi-load templates that have hte actual HFM account/entity names in them whereas production maps account for each company’s GL b.) Categories are different as we limit each FDM app to only the exact Category (Scenarios) required. c.) Periods are different as we limit each FDM app to only the needed periods required.

The solution for me was to implement a SQL direct copy routine for the information I need to move. This helps as I can : a.) automate this task b.) copy only what I want c.) Perform the task relatively quickly.

While the Workbench offers the ability to import / export components, I ran into trouble with it not correctly importing all of the data and it also restrcted my flexibility. Copying the entire database was not viable either as there were pieces I did not want to update….
The script below illustrates how to perform a copy via SQL. *bold*Please note that if you want to use this (or base a script off of this) that there’s absolutely no warranty and its use at your own risk.bold I’m fairly comfortable that this works fine (as I’ve tested this in our Dev), but you should test it on your own as well.

Also note, that this script does not copy ALL tables as I didn’t need them all for my purpose.

The script performs the following :

– Clears data from Target Database – Data Archives – Data Maps – Data
– Logs – Import Groups/Items – Validation Groups/Entities – Users / Partition Security – Partition Hierarchies / Links – Partitions (locations)
– Copies data from Source Database: – Import Groups / Items – Validation Groups / Items – Partitions (locations) – Partition Hierarchy / Links – Users / Partition Security
– Updates Parent Location setting on all Data Load locations (This is since I want all of my data load locations in the Budget / Forecast apps to use a * to * map. I added a new location in the Prod Database which is defined with the * to * mappings and when I copy everything over, I want the locations to use this map instead of their production G&L map.

-=-=-==-=-=-===-=-=-=-=-=-=-=-===-=-=-=-=-=-=-=-=-=-

[[code]]czo0MDk1OlwiLS0gRkRNIERhdGFiYXNlIDxzcGFuIHN0eWxlPVwiY29sb3I6IG5hdnk7XCI+XCdBdXRvIENvcHlcJzwvc3Bhbj4NCi0tIEF1e1smKiZdfXRob3IgOiBDaGFybGVzIEJleWVyDQotLSBEYXRlIDogNy8xLzIwMTANCi0tIERlc2NyaXB0aW9uIDogVGhpcyBzY3JpcHQgaXMgdXN7WyYqJl19ZWQgdG8gYXV0b21hdGljYWxseSAvIG1hbnVhbGx5IHN5bmMgdXAgZGF0YWJhc2UgYmV0d2VlbiBhIFNPVVJDRSBGRE0gYXBwbGljYXtbJiomXX10aW9uIGFuZCBhIA0KLS0gICAgICAgICAgICAgICAgREVTVElOQVRJT04gRkRNIGFwcGxpY2F0aW9uLg0KLS0gTk9URVMNCi0tICMje1smKiZdfVRBUkdFVERCIyMgLSBSZXBsYWNlIDxzcGFuIHN0eWxlPVwiY29sb3I6IG5hdnk7XCI+PGI+dGhpczwvYj48L3NwYW4+IHdpdGggdGhlIHtbJiomXX1uYW1lIG9mIHRoZSBEYXRhYmFzZSB0aGF0IHlvdSB3YW50IHRvIFNZTkMgDQotLSAjI1NPVVJDRURCIyMgLSBSZXBsYWNlIDxzcGFue1smKiZdfSBzdHlsZT1cImNvbG9yOiBuYXZ5O1wiPjxiPnRoaXM8L2I+PC9zcGFuPiB3aXRoIHRoZSBuYW1lIG9mIHRoZSBEYXRhYmFzZSB0aGF0IHtbJiomXX1pcyB0aGUgZGF0YSBzb3VyY2UNCg0KLS0gZGlzYWJsZSByZWZlcmVudGlhbCBpbnRlZ3JpdHkNCkVYRUMgc3BfTVNGb3JFYWNoVGFie1smKiZdfWxlIDxzcGFuIHN0eWxlPVwiY29sb3I6IG5hdnk7XCI+XCdBTFRFUiBUQUJMRSA/IE5PQ0hFQ0sgQ09OU1RSQUlOVCBBTExcJzwvc3Bhbj4Ne1smKiZdfQoNCi0tQ2xlYXIgVXNlciBTZWN1cml0eQ0KVFJVTkNBVEUgVEFCTEUgIyNUQVJHRVREQiMjLmRiby50U2VjVXNlclBhcnRpdGlvbg17WyYqJl19ClRSVU5DQVRFIFRBQkxFICMjVEFSR0VUREIjIy5kYm8udFN0cnVjdFBhcnRpdGlvbkxpbmtzDQpkZWxldGUgZnJvbSAjI1RBUkdFVHtbJiomXX1EQiMjLmRiby50U3RydWN0UGFydGl0aW9uSGllcmFyY2h5DQpUUlVOQ0FURSBUQUJMRSAjI1RBUkdFVERCIyMuZGJvLnREYXRhQXJje1smKiZdfWhpdmUNClRSVU5DQVRFIFRBQkxFICMjVEFSR0VUREIjIy5kYm8udERhdGFDaGVjaw0KDQotLUF0dGVtcHQgdG8gY2xlYXIgb3V0IHR7WyYqJl19aGUgdERhdGFNYXBTZWcgdGFibGVzDQpFWEVDIHNwX01TRm9yRWFjaFRhYmxlIDxzcGFuIHN0eWxlPVwiY29sb3I6IG5hdnk7XCI+XCc8L3tbJiomXX1zcGFuPg0KICBERUNMQVJFIEBUYWJsZU5hbWUgVmFyQ2hhcigxMDApDQogIFNldCBAVGFibGVOYW1lID0gUEFSU0VOQU1FKDxzcGFue1smKiZdfSBzdHlsZT1cImNvbG9yOiBuYXZ5O1wiPlwnXCc8L3NwYW4+PzxzcGFuIHN0eWxlPVwiY29sb3I6IG5hdnk7XCI+XCdcJzwvc3Bhbj4sMSkNCiAgSXtbJiomXX1GICBsZWZ0KEBUYWJsZU5hbWUsOCkgPSA8c3BhbiBzdHlsZT1cImNvbG9yOiBuYXZ5O1wiPlwnXCc8L3NwYW4+dERhdGFNYXA8c3BhbiBzdHtbJiomXX15bGU9XCJjb2xvcjogbmF2eTtcIj5cJ1wnPC9zcGFuPg0KICAgICAgVFJVTkNBVEUgVEFCTEUgIyNUQVJHRVREQiMjLj8gDQo8c3BhbiBzdHtbJiomXX15bGU9XCJjb2xvcjogbmF2eTtcIj5cJyAgPC9zcGFuPg0KR08NCg0KLS1BdHRlbXB0IHRvIGNsZWFyIG91IHRoZSB0RGF0YVNlZyB0YWJse1smKiZdfWVzDQpFWEVDIHNwX01TRm9yRWFjaFRhYmxlIDxzcGFuIHN0eWxlPVwiY29sb3I6IG5hdnk7XCI+XCc8L3NwYW4+DQogIERFQ0xBUkUgQFR7WyYqJl19YWJsZU5hbWUgVmFyQ2hhcigxMDApDQogIFNldCBAVGFibGVOYW1lID0gUEFSU0VOQU1FKDxzcGFuIHN0eWxlPVwiY29sb3I6IG5hdnl7WyYqJl19O1wiPlwnXCc8L3NwYW4+PzxzcGFuIHN0eWxlPVwiY29sb3I6IG5hdnk7XCI+XCdcJzwvc3Bhbj4sMSkNCiAgSUYgIGxlZnQoQFRhYmxlTmFtZSx7WyYqJl19OCkgPSA8c3BhbiBzdHlsZT1cImNvbG9yOiBuYXZ5O1wiPlwnXCc8L3NwYW4+dERhdGFTZWc8c3BhbiBzdHlsZT1cImNvbG9yOiBuYXZ5O1wiPntbJiomXX1cJ1wnPC9zcGFuPg0KICAgICAgVFJVTkNBVEUgVEFCTEUgIyNUQVJHRVREQiMjLj8gDQo8c3BhbiBzdHlsZT1cImNvbG9yOiBuYXZ5O1wiPntbJiomXX1cJyAgPC9zcGFuPg0KR08NCg0KVFJVTkNBVEUgVEFCTEUgIyNUQVJHRVREQiMjLmRiby50TG9nQWN0aXZpdHkNClRSVU5DQVRFIFRBQntbJiomXX1MRSAjI1RBUkdFVERCIyMuZGJvLnRMb2dQcm9jZXNzDQpUUlVOQ0FURSBUQUJMRSAjI1RBUkdFVERCIyMuZGJvLnREYXRhQXJjaGl2e1smKiZdfWUNCmRlbGV0ZSBmcm9tICMjVEFSR0VUREIjIy5kYm8udFNlY1VzZXINCg0KZGVsZXRlIGZyb20gIyNUQVJHRVREQiMjLmRiby50UE97WyYqJl19VlBhcnRpdGlvbg0KDQpUUlVOQ0FURSBUQUJMRSAjI1RBUkdFVERCIyMuZGJvLnRCaHZWYWxFbnRJdGVtDQpkZWxldGUgZnJvbSAjI3tbJiomXX1UQVJHRVREQiMjLmRiby50Qmh2VmFsRW50R3JvdXANCg0KVFJVTkNBVEUgVEFCTEUgIyNUQVJHRVREQiMjLmRiby50Qmh2SW1wSXRle1smKiZdfW1GaWxlDQpkZWxldGUgZnJvbSAjI1RBUkdFVERCIyMuZGJvLnRCaHZJbXBHcm91cA0KDQotLSBSRUNPUFkgRGF0YSBmcm9tIFByb2R7WyYqJl19IERCIHRvIEJ1ZGdldCBEQg0KaW5zZXJ0IGludG8gIyNUQVJHRVREQiMjLmRiby50Qmh2SW1wR3JvdXANCiAgIHNlbGVjdCAqIGZyb3tbJiomXX1tICMjU09VUkNFREIjIy5kYm8udEJodkltcEdyb3VwDQoNCmluc2VydCBpbnRvICMjVEFSR0VUREIjIy5kYm8udEJodlZhbEVudEdye1smKiZdfW91cA0KICAgc2VsZWN0ICogZnJvbSAjI1NPVVJDRURCIyMuZGJvLnRCaHZWYWxFbnRHcm91cA0KDQppbnNlcnQgaW50byAjI1RBUkd7WyYqJl19RVREQiMjLmRiby50Qmh2VmFsRW50SXRlbQ0KICAgc2VsZWN0ICogZnJvbSAjI1NPVVJDRURCIyMuZGJvLnRCaHZWYWxFbnRJdGVtDXtbJiomXX0KDQppbnNlcnQgaW50byAjI1RBUkdFVERCIyMuZGJvLnRCaHZJbXBJdGVtRmlsZQ0KICAgc2VsZWN0ICogZnJvbSAjI1NPVVJDRURCe1smKiZdfSMjLmRiby50Qmh2SW1wSXRlbUZpbGUNCg0KaW5zZXJ0IGludG8gIyNUQVJHRVREQiMjLmRiby50UE9WUGFydGl0aW9uDQogICBzZWx7WyYqJl19ZWN0ICogZnJvbSAjI1NPVVJDRURCIyMuZGJvLnRQT1ZQYXJ0aXRpb24NCg0KaW5zZXJ0IGludG8gIyMJVEFSR0VUREIjIy5kYm8udHtbJiomXX1TdHJ1Y3RQYXJ0aXRpb25IaWVyYXJjaHkNCiAgIHNlbGVjdCAqIGZyb20gIyNTT1VSQ0VEQiMjLmRiby50U3RydWN0UGFydGl0aW9ue1smKiZdfUhpZXJhcmNoeQ0KDQppbnNlcnQgaW50byAjI1RBUkdFVERCIyMuZGJvLnRTdHJ1Y3RQYXJ0aXRpb25MaW5rcw0KICAgc2VsZWN0ICp7WyYqJl19IGZyb20gIyNTT1VSQ0VEQiMjLmRiby50U3RydWN0UGFydGl0aW9uTGlua3MNCg0KaW5zZXJ0IGludG8gIyNUQVJHRVREQiMjLmRib3tbJiomXX0udFNlY1VzZXINCiAgIHNlbGVjdCAqIGZyb20gIyNTT1VSQ0VEQiMjLmRiby50U2VjVXNlcg0KDQppbnNlcnQgaW50byAjI1RBUkdFe1smKiZdfVREQiMjLmRiby50U2VjVXNlclBhcnRpdGlvbg0KICAgc2VsZWN0ICogZnJvbSAjI1NPVVJDRURCIyMuZGJvLnRTZWNVc2VyUGFydGl7WyYqJl19dGlvbg0KDQotLUF0dGVtcHQgdG8gPHNwYW4gc3R5bGU9XCJjb2xvcjogbmF2eTtcIj48Yj5pbXBvcnQ8L2I+PC9zcGFuPiBkYXRhDQpTe1smKiZdfUVUIElERU5USVRZX0lOU0VSVCAjI1RBUkdFVERCIyMuZGJvLnREYXRhTWFwIE9ODQppbnNlcnQgaW50byAjI1RBUkdFVERCIyMuZGJ7WyYqJl19by50RGF0YU1hcCAoUGFydGl0aW9uS2V5LCBEaW1OYW1lLCBTcmNLZXksIFNyY0Rlc2MsIFRhcmdLZXksIFdoZXJlQ2xhdXNlVHlwZXtbJiomXX0sIFdoZXJlQ2xhdXNlVmFsdWUsIA0KICAgICAgQ2hhbmdlU2lnbiwgU2VxdWVuY2UsIERhdGFLZXksIFZCU2NyaXB0KQ0KICAgc2Vse1smKiZdfWVjdCBQYXJ0aXRpb25LZXksIERpbU5hbWUsIFNyY0tleSwgU3JjRGVzYywgVGFyZ0tleSwgV2hlcmVDbGF1c2VUeXBlLCBXaGVyZUN7WyYqJl19bGF1c2VWYWx1ZSwgQ2hhbmdlU2lnbiwgU2VxdWVuY2UsIERhdGFLZXksIA0KICAgICAgIFZCU2NyaXB0IGZyb20gIyNTT1VSQ0VEQntbJiomXX0jIy5kYm8udERhdGFNYXANClNFVCBJREVOVElUWV9JTlNFUlQgIyNUQVJHRVREQiMjLmRiby50RGF0YU1hcCBPRkYNCg0KLS0gVXBke1smKiZdfWF0ZSBwYXJlbnQgbG9jYXRpb25zIC4uLg0KdXBkYXRlICMjVEFSR0VUREIjIy5kYm8udFBPVlBhcnRpdGlvbg0KICBzZXQgUGFydFB7WyYqJl19YXJlbnQgPSA8c3BhbiBzdHlsZT1cImNvbG9yOiBuYXZ5O1wiPlwnQnVkZ2V0VGVtcGxhdGVMb2NcJzwvc3Bhbj4NCiB3aGVyZSANCiAgIFB7WyYqJl19YXJ0TmFtZSAgPHNwYW4gc3R5bGU9XCJjb2xvcjogbmF2eTtcIj5cJ0J1ZGdldFRlbXBsYXRlTG9jXCc8L3NwYW4+IGFuZCBQYXJ0Q29udHJ7WyYqJl19b2xzVHlwZSA9IDENCg0KLS0gZW5hYmxlIHJlZmVyZW50aWFsIGludGVncml0eSBhZ2Fpbg0KRVhFQyBzcF9NU0ZvckVhY2hUYWJsZXtbJiomXX0gPHNwYW4gc3R5bGU9XCJjb2xvcjogbmF2eTtcIj5cJ0FMVEVSIFRBQkxFID8gQ0hFQ0sgQ09OU1RSQUlOVCBBTExcJzwvc3Bhbj4NCkdPXCJ7WyYqJl19O3tbJiomXX0=[[/code]]

  • 1
  • 2